unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: "Neil Jerram" <neiljerram@googlemail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: vm branch now uses vm repl by default
Date: Wed, 10 Sep 2008 20:51:23 +0200	[thread overview]
Message-ID: <m3d4jb7s2c.fsf@pobox.com> (raw)
In-Reply-To: <49dd78620809091543j2a811a01lffe13d9be3c6ee7d@mail.gmail.com> (Neil Jerram's message of "Wed, 10 Sep 2008 00:43:39 +0200")

Hi,

On Wed 10 Sep 2008 00:43, "Neil Jerram" <neiljerram@googlemail.com> 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/




  reply	other threads:[~2008-09-10 18:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-09  6:48 vm branch now uses vm repl by default Andy Wingo
2008-09-09  8:27 ` Neil Jerram
2008-09-09 17:59   ` Andy Wingo
2008-09-09 22:27     ` Neil Jerram
2008-09-09  8:41 ` Ludovic Courtès
2008-09-09 18:13   ` Andy Wingo
2008-09-09 21:01     ` Ludovic Courtès
2008-09-10 19:05       ` Andy Wingo
2008-09-09 22:43 ` Neil Jerram
2008-09-10 18:51   ` Andy Wingo [this message]
2008-09-10 21:24     ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3d4jb7s2c.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=neiljerram@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).