From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: racing srfi-18 threads Date: Thu, 03 Dec 2009 22:52:44 +0000 Message-ID: <878wdjpt4z.fsf@ossau.uklinux.net> References: <2e6d10880911060129s538fab2cv84805475450f33d0@mail.gmail.com> <2e6d10880911060652g56092de3g649c540e54102c05@mail.gmail.com> <87bpjcy4bc.fsf@ossau.uklinux.net> <87skceglog.fsf@ossau.uklinux.net> <87my2iuksq.fsf@ossau.uklinux.net> <87ws1582wk.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259880844 14362 80.91.229.12 (3 Dec 2009 22:54:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Dec 2009 22:54:04 +0000 (UTC) To: Guile Development Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Dec 03 23:53:57 2009 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 1NGKYY-0007Gi-Cr for guile-devel@m.gmane.org; Thu, 03 Dec 2009 23:53:51 +0100 Original-Received: from localhost ([127.0.0.1]:48984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGKYY-0002kQ-7H for guile-devel@m.gmane.org; Thu, 03 Dec 2009 17:53:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NGKXh-00029L-60 for guile-devel@gnu.org; Thu, 03 Dec 2009 17:52:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NGKXc-000240-Gs for guile-devel@gnu.org; Thu, 03 Dec 2009 17:52:56 -0500 Original-Received: from [199.232.76.173] (port=54295 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NGKXc-00023p-B8 for guile-devel@gnu.org; Thu, 03 Dec 2009 17:52:52 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]:54228) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NGKXb-0005Cy-Po for guile-devel@gnu.org; Thu, 03 Dec 2009 17:52:52 -0500 Original-Received: from arudy (host86-145-153-90.range86-145.btcentralplus.com [86.145.153.90]) by mail3.uklinux.net (Postfix) with ESMTP id 336141F6667 for ; Thu, 3 Dec 2009 22:52:48 +0000 (GMT) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 96ACC38024 for ; Thu, 3 Dec 2009 22:52:44 +0000 (GMT) In-Reply-To: <87ws1582wk.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed, 02 Dec 2009 21:46:51 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:9735 Archived-At: Neil Jerram writes: > [...] wondering whether and how we > will provide similar debugging facilities for compiled code as we have > in 1.8.x for interpreted code. Some more thoughts here, to try to build a complete new picture. Things that we can do quite nicely in 1.8.x are: - stack inspection - seeing the frames and what is happening, for context - mapping back to source code - querying variable values - evaluating an expression in a frame's local environment - breakpoints - tracing - single stepping. We should try to include profiling and code coverage in the picture. My thoughts for doing this in 2.0 are as follows. - Single stepping, breakpoints, code coverage and tracing can all be done by instrumenting code - either in Scheme, or with lower-level language ops that somehow get inserted as code is compiled. - The more I think about this, the more it seems clearly preferable to the 1.8.x evaluator traps model - i.e. where there are ways of _marking_ code in some way, and the evaluator or VM calls out to a hook when it sees one of these marks. It's a simpler solution, and... - It in particular removes the need for most of the complexity that we have in 1.8.x's (ice-9 debugging traps). The complexity is mostly about wanting to say 'do THIS when you start executing procedure FOO', but the lowlevel traps interface not allowing us to specify either 'THIS' or 'when you start executing procedure FOO' precisely. (All we can say is 'call a globally-defined function when you start executing any of the currently marked procedures'.) - I'm not clear how this interacts with optimisation... What happens when an optimisation reorders or eliminates code with a breakpoint? How do we present this to the user? It feels like a soluble problem though. - Instrumentation-based single-stepping would be more like edebug than what we have in 1.8.x - i.e. the mode of operation would probably be to instrument the whole of the body of a given function. But I think that would be fine (and consistent for our plan for future emacs domination :-)). (In contrast, 1.8.x single-stepping doesn't require prior instrumentation, and allows stepping over function boundaries.) - An unfortunate consequence of psyntax is backtraces being harder to read, and to correlate back to source code, because of all the alpha-renamed variables. When paused at a breakpoint, I think this also makes it harder for the user to ask what the value of a given variable is. Is there anything we can do about this - such as mapping all the variable names back to their names in the original source code? - As one of Andy's eval commits says, we don't have local-eval any more and so can't currently do "evaluate in a stack frame". I suppose the most important case here is querying local variable values; is there a reasonable solution for that? Any thoughts on that? > (SLIB has stuff like this too. I wonder if it would just work.) (Currently blocked by SLIB not loading at all in 1.9/2.0: scheme@(guile-user)> (use-modules (ice-9 slib)) ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-autocompile argument to disable. ;;; compiling /usr/share/slib/guile.init ;;; WARNING: compilation of /usr/share/slib/guile.init failed: ;;; key syntax-error, throw args (sc-expand "~a in ~a" ("unexpected syntax" define) #f) ERROR: In procedure sc-expand: ERROR: unexpected syntax in define ) Regards, Neil