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,gmane.lisp.guile.user Subject: Re: racing srfi-18 threads Date: Thu, 10 Dec 2009 20:53:10 +0100 Message-ID: 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 1260476178 17659 80.91.229.12 (10 Dec 2009 20:16:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2009 20:16:18 +0000 (UTC) Cc: guile-user@gnu.org, Guile Development To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Dec 10 21:16:09 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 1NIpQm-0004h2-5W for guile-devel@m.gmane.org; Thu, 10 Dec 2009 21:16:08 +0100 Original-Received: from localhost ([127.0.0.1]:39977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIpQl-00062w-PI for guile-devel@m.gmane.org; Thu, 10 Dec 2009 15:16:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIpCv-0000Wc-Ey for guile-devel@gnu.org; Thu, 10 Dec 2009 15:01:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIpCr-0000UO-9d for guile-devel@gnu.org; Thu, 10 Dec 2009 15:01:49 -0500 Original-Received: from [199.232.76.173] (port=56230 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIpCr-0000UJ-3Z; Thu, 10 Dec 2009 15:01:45 -0500 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:50529 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NIpCq-0005SY-MF; Thu, 10 Dec 2009 15:01:44 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E87EB86E01; Thu, 10 Dec 2009 15:01:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=4oLiUf9ksvH/nVl9/vEeEUjpbBA=; b=cpa95g OUy5kMZO15dMf5LqvcHv3m7n2k9ftZ4ixdWGV9ZLJVVrUhwDeRDWQAOQiqFR+bSx RtvIKegZjt8GmKA5DEyPMO2j97xHPwKQvXOesDFWUSPO3tTV8qOLU7uf2RcxsiyC BC6Jrga52wlbChF3oLgW+YW+bQZQwptFU1D4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=CDM0mHFHN7DCmspDeFiC+W4PqtAt9mN9 8ltPPVWpWhbVTy42hwO1Cl2pcN0ECC1PbrUUZg/o995yvjN04bcX0EpP8Kc91p39 UZLcCI26EQvnYHnxvYIlMn7+TDJFJjPNtlySJXec1F799X2XCG2BiEa9ZieXJzAb Rfx29xBzzfQ= Original-Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6380F86DFF; Thu, 10 Dec 2009 15:01:40 -0500 (EST) Original-Received: from unquote (unknown [81.38.189.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 18B7386DFB; Thu, 10 Dec 2009 15:01:35 -0500 (EST) 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.0.92 (gnu/linux) X-Pobox-Relay-ID: D4C50B00-E5C6-11DE-AF42-DC0DEE7EF46B-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: 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:9750 gmane.lisp.guile.user:7532 Archived-At: Hi Neil, On Wed 02 Dec 2009 22:46, Neil Jerram writes: > Neil Jerram writes: > >> I now have it down to this: a program compiled inside the RHS of a >> define-syntax form apparently has no meta; whereas the same program >> compiled outside a define-syntax form does have meta: > > Apologies for taking so long to follow up on this! Dude, my apologies for not tracking mail... This particular bug was due to a bad check in compile-assembly.scm:make-meta. Fixed in 8986ff7ae9dcaae79d3ab262c360a6cbbc86c263. > I've been trying to remedy my lack of detailed understanding about how > compilation works, and that has led me to wondering whether and how we > will provide similar debugging facilities for compiled code as we have > in 1.8.x for interpreted code. I would hope so! > One option would be not to take the 1.8.x approach at all (i.e. using > special hooks from the core of the evaluator/VM) but instead rely on > instrumenting code at runtime. I had a quick play with this and it > seems quite simple and promising. That is indeed useful, and robust. Some thoughts... 1. Something like your trace procedure does seem to be quite useful. 2. At the same time, we should be able to trace any procedure at runtime without modifying it -- whether by using a different VM (possible) or by enabling hooks on the current VM. 3. When it comes time to have native compilation, things get trickier. Did you see today's LWN article on ftrace? It looks really really sweet. http://lwn.net/SubscriberLink/365835/07f149ad48a74856/ -- and do subscribe if you're not already, &c &c. The compiler could easily instrument interesting pieces of code with NOPs, and a tracer could patch the code at runtime. Even more easy would be having the compiler produce actual calls to trace procedures at various points, for serious debugging. Also there are hardware breakpoints, but that's trickier. Dunno, my thoughts here are scattered. > Yes, I know I should write that with define-syntax instead. :-) Probably yes :) > We should be able to do breakpoints like this too, using either the > command line or the GDS debugger - although I'm not sure how much of the > stack inspection facilities will immediately work. I'll try that > next. There is the break instruction. We have code for inspecting the local vars of a stack frame -- see program.scm and frame.scm. > I don't see how single-stepping could easily be implemented this way, > though. I think that may require hooks in the VM. But then again, > would single stepping through VM operations be useful and comprehensible > anyway? Not usually no. But sometimes. More often expression-level stepping would be nice, or at least stepping function calls. Cheers, Andy -- http://wingolog.org/