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: Edebug & lexical scope Date: Fri, 18 May 2012 15:54:49 -0400 Message-ID: References: <33870303.post@talk.nabble.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1337370899 16842 80.91.229.3 (18 May 2012 19:54:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 18 May 2012 19:54:59 +0000 (UTC) Cc: Emacs-devel@gnu.org To: egnarts-ms Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 18 21:54:59 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SVTGM-0006Fq-Q4 for ged-emacs-devel@m.gmane.org; Fri, 18 May 2012 21:54:58 +0200 Original-Received: from localhost ([::1]:38718 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVTGM-0002pa-9x for ged-emacs-devel@m.gmane.org; Fri, 18 May 2012 15:54:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVTGJ-0002pG-Fp for Emacs-devel@gnu.org; Fri, 18 May 2012 15:54:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVTGH-0007oP-AI for Emacs-devel@gnu.org; Fri, 18 May 2012 15:54:55 -0400 Original-Received: from ironport-out.teksavvy.com ([206.248.143.162]:43558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVTGH-0007oK-5h for Emacs-devel@gnu.org; Fri, 18 May 2012 15:54:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOMAh09FpZld/2dsb2JhbAAwB6NCgQiBdQEBBAFWIwULCzQSFBgNJIgTohGJRoI3AwIKDwMDQwwDgz4Dg3AEo2OEWIE3Dg X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="181071991" Original-Received: from 69-165-153-93.dsl.teksavvy.com (HELO pastel.home) ([69.165.153.93]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 May 2012 15:54:50 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E2D4B59577; Fri, 18 May 2012 15:54:49 -0400 (EDT) In-Reply-To: <33870303.post@talk.nabble.com> (egnarts-ms's message of "Fri, 18 May 2012 06:30:00 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.143.162 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150559 Archived-At: > Currently (Emacs 24.0.97) Edebug cannot evaluate lexical variables when it > is suspended (by "e" or "M-:"). Indeed. The same holds for the normal (backtrace-style) debugger. > It seems that I've managed to make M-: evaluate lexical variables. I've > created the following C subroutine; it does the same job as `eval', but > first of all it scans "specpdl" (the stack of bindings of symbols) searching > for the most recent value of Qinternal_interpreter_environment which is not > eq to nil. Thanks. This is a good way to fix the problem (tho it still doesn't solve the issue for the case of the normal debugger where you want to look at the local variable of a lexical-binding byte-code routine, because in that case the var names are purely gone). The only problem with it is that it relies on all the stack frames (until the interesting ones) using dynamic binding. E.g. if/when we switch edebug to lexical-binding we'll have a problem. Also in the case of the normal debugger, we would generally want to be able to get the value of a variable in a particular stack frame. So it would be better to have an "eval-in-frame" which receives some description of the stack frame to use (and of course, more primitives to get a handle of the current stack frame as well as the Nth previous one). Stefan