From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: vm branch now uses vm repl by default Date: Wed, 10 Sep 2008 20:51:23 +0200 Message-ID: References: <49dd78620809091543j2a811a01lffe13d9be3c6ee7d@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 1221074514 709 80.91.229.12 (10 Sep 2008 19:21:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Sep 2008 19:21:54 +0000 (UTC) Cc: guile-devel To: "Neil Jerram" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 10 21:22:50 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 1KdVGv-00045j-DY for guile-devel@m.gmane.org; Wed, 10 Sep 2008 21:22:37 +0200 Original-Received: from localhost ([127.0.0.1]:37209 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdVFu-0001J2-Mk for guile-devel@m.gmane.org; Wed, 10 Sep 2008 15:21:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdVFo-0001Gv-KH for guile-devel@gnu.org; Wed, 10 Sep 2008 15:21:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdVFj-00012G-VB for guile-devel@gnu.org; Wed, 10 Sep 2008 15:21:28 -0400 Original-Received: from [199.232.76.173] (port=43765 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdVFj-00011w-Si for guile-devel@gnu.org; Wed, 10 Sep 2008 15:21:23 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:40414 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdVFj-0007qD-LC for guile-devel@gnu.org; Wed, 10 Sep 2008 15:21:23 -0400 Original-Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 7E4FD7B5F3; Wed, 10 Sep 2008 15:21:06 -0400 (EDT) Original-Received: from unquote (251.Red-83-32-65.dynamicIP.rima-tde.net [83.32.65.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id F29FF7B5F2; Wed, 10 Sep 2008 15:21:02 -0400 (EDT) In-Reply-To: <49dd78620809091543j2a811a01lffe13d9be3c6ee7d@mail.gmail.com> (Neil Jerram's message of "Wed, 10 Sep 2008 00:43:39 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Pobox-Relay-ID: 9DB53100-7F6D-11DD-9453-3113EBD4C077-02397024!a-sasl-quonix.pobox.com X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) 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:7660 Archived-At: Hi, On Wed 10 Sep 2008 00:43, "Neil Jerram" writes: > I guess source information is of interest for debugging Of course :) > you've observed previously elsewhere that the VM doesn't yet have much > debugging support - by which I presume you mean something like the > traps that the evaluator has. Oh it has some. Here are the hooks: vm-next-hook vm-apply-hook vm-boot-hook vm-return-hook vm-break-hook vm-exit-hook vm-halt-hook vm-enter-hook They sound sufficient, but perhaps more could be added. Unless I misunderstand what the traps do (which is likely). > So I was just wondering if we actually _need_ any debugging support in > the VM. Certainly we do for debugging the VM itself. But besides that, if the VM will be the way that people will want to run their programs, they need good backtraces at the very least. Which implies at least source information. I think the only thing that is missing at this point is procedure names (which I haven't spent enough time figuring out how to push them down the compilation pipeline, but the support is there), and spaghetti stacks, which are also needed to support call/cc. > Then another question is whether we can assume that the VM behaves > equivalently to the evaluator. I think that this is a precondition for merging vm to master. > code that doesn't have side effects? If you believe that, I've got a type system in Scotland I'd like to sell you ;-) Peace, Andy -- http://wingolog.org/