From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Patches for wip-rtl Date: Mon, 22 Apr 2013 22:38:02 -0400 Message-ID: References: <871ua2jo4l.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b15b17d470b5d04dafe1463 X-Trace: ger.gmane.org 1366684707 17040 80.91.229.3 (23 Apr 2013 02:38:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2013 02:38:27 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 23 04:38:31 2013 Return-path: Envelope-to: guile-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 1UUT7m-0007Ic-L4 for guile-devel@m.gmane.org; Tue, 23 Apr 2013 04:38:30 +0200 Original-Received: from localhost ([::1]:53676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUT7m-0006pq-5j for guile-devel@m.gmane.org; Mon, 22 Apr 2013 22:38:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUT7i-0006pk-Es for guile-devel@gnu.org; Mon, 22 Apr 2013 22:38:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUT7h-0004Qp-1P for guile-devel@gnu.org; Mon, 22 Apr 2013 22:38:26 -0400 Original-Received: from mail-pd0-f176.google.com ([209.85.192.176]:35680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUT7g-0004Qk-Nv for guile-devel@gnu.org; Mon, 22 Apr 2013 22:38:24 -0400 Original-Received: by mail-pd0-f176.google.com with SMTP id r11so105832pdi.7 for ; Mon, 22 Apr 2013 19:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=bFQrxbHdEZgQkH0BbISo9GliXwAuRre2xwBFpv4pNXQ=; b=njC8Bg7PA2MaCGniC5lPGrAjMuBHB8x7vV6zFNFPMXHru0cZlQaZHbplPyTJlE0PJY UfXeeSuH2WEC7PI+WeQ6aDS7tqlNePY8z8Nzw+JYcy6DtDBkxFuA0KY0rHc8bz++wUMl QP71N5tyk6gYVkXVVJr4I+zzxR2VNIxY9zjd0UEPOAwMsp5iLRmmlbrnh9FThZ1pWl/h Ktbcw5oIlg+i7ZHD/3ZnFtTbMHSPcmIPZAfy9b2yxSKxFEJvZgn7M2JFuNIk7Uh4VTJ1 AyuLBsGhcRhXVf2BEY1XbD1p/+zn2MPNLQnapUTF1zE9AYHK7xdgwGDjmWDKzkhAVq1k cIZQ== X-Received: by 10.68.200.10 with SMTP id jo10mr36314787pbc.53.1366684703589; Mon, 22 Apr 2013 19:38:23 -0700 (PDT) Original-Received: by 10.68.7.9 with HTTP; Mon, 22 Apr 2013 19:38:02 -0700 (PDT) In-Reply-To: <871ua2jo4l.fsf@pobox.com> X-Google-Sender-Auth: DF-rNo9-Y7adlBZvVvQpKq0jx5g X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.192.176 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16289 Archived-At: --047d7b15b17d470b5d04dafe1463 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Mon, Apr 22, 2013 at 4:39 PM, Andy Wingo wrote: > Hi :) > > Thanks for working on the RTL VM! > Thanks for doing most of the work! I'm happy to help. :-) > First of all, sorry about that linker error. I'm trying to make RTL > programs more debuggable by hacking on the linker, so that it emits > proper debugging information. I should have caught that typo though! > Debugging would be great. I have thought about stopping this and working on debugging stuff some, but that actually seems harder than what I'm doing now, and I would like to get the compiler working. > I think however that the strategy of making the VM somehow more > resilient is not going to work. There are so many ways that invalid > instructions can make the VM fail -- and you have no idea what you can > rely on if those invariants fail. So it doesn't seem to me that it's > possible to do that job well at all, and for that reason it seems to me > that we shouldn't try very hard. > I assume you're talking about the box-ref and box-set! stuff with checking for non-variables, right? I agree in general, but those instructions could plausibly be emitted for any code that uses module introspection to get its own variable objects, right?. At that point the not-a-variable error would be a user type error, and so I think it's better to throw wrong-type-arg. (But of course, that's not my real motivation - I just happened to hit this while debugging the compiler.) And I don't know how you've been able to get as far as you have with the > deplorable state of the debugging infrastructure. You can't even > disassemble a function you just made! I'll be working on that this > week; we'll see what happens. > > So in summary, dunno. Surely there is some way we can do things better, > but I wanted to register my skepticism for this line of hacking. What > do you think? > First of all, I agree that debugging infrastructure would be great. I'm very glad you're working on it - that should help a lot. I'm not sure if I have much to add there right now, but I will keep it in mind. As for the line of hacking, as I said above, I think in the particular case of box-ref and box-set! it's justified; I don't know in general. I certainly agree that once the VM's internal state is corrupt, all bets are off, and we probably won't be able to continue. One thing that would be interesting - and I don't know if we do this now - is using different VMs for different parts of the code. Specifically, if the REPL ran in a different VM than user code, then the REPL wouldn't die in these cases. That might also enable cool debugging things, like single-stepping the user VM and examining its registers. I noticed that we already have support for changing the active VM. What do you think? Best, Noah --047d7b15b17d470b5d04dafe1463 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Mon, Apr 22, 2013 at 4:39 PM, Andy Wingo <wingo@pobox.co= m> wrote:
Hi :)

Thanks for working on the RTL VM!

Thank= s for doing most of the work! I'm happy to help. :-)
=A0<= /div>
First of all, sorry about that linker error. =A0I'm trying to make RTL<= br> programs more debuggable by hacking on the linker, so that it emits
proper debugging information. =A0I should have caught that typo though!
=

Debugging would be great. I have thought a= bout stopping this and working on debugging stuff some, but that actually s= eems harder than what I'm doing now, and I would like to get the compil= er working.
=A0
I think however that the strategy of making the VM somehow more
resilient is not going to work. =A0There are so many ways that invalid
instructions can make the VM fail -- and you have no idea what you can
rely on if those invariants fail. =A0So it doesn't seem to me that it&#= 39;s
possible to do that job well at all, and for that reason it seems to me
that we shouldn't try very hard.

I = assume you're talking about the box-ref and box-set! stuff with checkin= g for non-variables, right? I agree in general, but those instructions coul= d plausibly be emitted for any code that uses module introspection to get i= ts own variable objects, right?. At that point the not-a-variable error wou= ld be a user type error, and so I think it's better to throw wrong-type= -arg. (But of course, that's not my real motivation - I just happened t= o hit this while debugging the compiler.)

And I don't know how you've been able to get as far as you have wit= h the
deplorable state of the debugging infrastructure. =A0You can't even
disassemble a function you just made! =A0I'll be working on that this week; we'll see what happens.

So in summary, dunno. =A0Surely there is some way we can do things better,<= br> but I wanted to register my skepticism for this line of hacking. =A0What do you think?

First of all, I agree tha= t debugging infrastructure would be great. I'm very glad you're wor= king on it - that should help a lot. I'm not sure if I have much to add= there right now, but I will keep it in mind.

As for the line of hacking, as I said above, I think in the = particular case of box-ref and box-set! it's justified; I don't kno= w in general. I certainly agree that once the VM's internal state is co= rrupt, all bets are off, and we probably won't be able to continue. One= thing that would be interesting - and I don't know if we do this now -= is using different VMs for different parts of the code. Specifically, if t= he REPL ran in a different VM than user code, then the REPL wouldn't di= e in these cases. That might also enable cool debugging things, like single= -stepping the user VM and examining its registers. I noticed that we alread= y have support for changing the active VM. What do you think?

Best,
Noah

--047d7b15b17d470b5d04dafe1463--