From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Christopher Allan Webber Newsgroups: gmane.lisp.guile.user Subject: Re: Stack traces Date: Thu, 18 May 2017 08:38:49 -0500 Message-ID: <87vaoy709i.fsf@dustycloud.org> References: <87h93wto3y.fsf_-_@gnu.org> <87mvdn4gam.fsf@dustycloud.org> <641f554a-3672-d71a-78cd-f32f5287f98d@hypermove.net> <34F40DF4-899A-4400-A2F6-820EFB3C66FD@gmail.com> <87efyjqt6c.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1495114768 22409 195.159.176.226 (18 May 2017 13:39:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 May 2017 13:39:28 +0000 (UTC) User-Agent: mu4e 0.9.18; emacs 25.2.1 Cc: Andy Wingo , guile-user@gnu.org, Matt Wette To: Amirouche Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu May 18 15:39:22 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dBLeB-0005bN-K3 for guile-user@m.gmane.org; Thu, 18 May 2017 15:39:19 +0200 Original-Received: from localhost ([::1]:53982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dBLeG-0005rH-Ta for guile-user@m.gmane.org; Thu, 18 May 2017 09:39:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dBLdl-0005qE-9W for guile-user@gnu.org; Thu, 18 May 2017 09:38:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dBLdk-0001cN-53 for guile-user@gnu.org; Thu, 18 May 2017 09:38:53 -0400 Original-Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:34420) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dBLdj-0001c5-Va for guile-user@gnu.org; Thu, 18 May 2017 09:38:52 -0400 Original-Received: from oolong (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 1089926638; Thu, 18 May 2017 09:38:50 -0400 (EDT) In-reply-to: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c02::f03c:91ff:feae:cb51 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13726 Archived-At: Amirouche writes: > Le 27/02/2017 =C3=A0 21:23, Andy Wingo a =C3=A9crit : >> On Sat 18 Feb 2017 20:59, Amirouche writes: >> >>> How do you access variables in the REPL? >> ,locals >> >> Andy > It doesn't display something that I can use. (Returning to this few-months-old thread...) Yes, I frequently find that ,locals does not display much information... it seems to be a toss-up whether the variables I need will be contained in it, so I've reduced the amount I use the actual debugger system in Guile a lot. A shame, because it seems really nice. Because of this, I think I do what a lot of Guile hackers do (which is totally undocumented in the manual, so only people who have been hanging around with someoen else who knows tend to know about it), which is to use (pk) everywhere. It's not as nice as being able to play with local variables at the REPL though! Matt's example from earlier in the thread seems simple enough... as a recap: (use-modules (system repl repl)) (use-modules (system repl debug)) (define-syntax-rule (trap-here) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t))) (define (foo) (let iter ((sum 0) (vals '(1 2 3 5 8 2))) (trap-here) (if (null? vals) sum (iter (+ sum (car vals)) (cdr vals))))) (foo) Looking at that, I would *think* that at minimum, sum and vals would be available when I run ,locals. I couldn't understand why they weren't: scheme@(guile-user)> (foo) scheme@(guile-user) [1]> ,locals No local variables. But then I ran ,optimize, and that made it obvious what's happening: (define (foo) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)) (start-repl #:debug (make-debug (stack->vector (make-stack #t)) 0 "trap!" #t)) 21) Ah... the compiler was being so smart that it did all the work up front already! ;) Pretty cool from a performance and optimization perspective (I'm still floored that Guile is able to do optimizations like that!), but it's not as helpful from a debugging perspective maybe? Maybe there could be a way to do something like this: scheme@(guile-user)> ,optimize-less ;;; * user re-evaluates code they want to debug * scheme@(guile-user)> (foo) scheme@(guile-user) [1]> ,locals Local variables: $23 =3D sum =3D 0 $24 =3D vals =3D '(1 2 3 5 8 2) scheme@(guile-user) [1]> ,q ;;; User has done debugging scheme@(guile-user)> ,optimize-more ;;; User can now re-evaluate their code with all the optimizations in ;;; place! scheme@(guile-user)> Thoughts? - Chris