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: [PATCH] New division operators, and optimization for fractions Date: Sat, 12 Feb 2011 21:19:45 +0100 Message-ID: References: <860989.4731.qm@web114104.mail.gq1.yahoo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1297541692 14560 80.91.229.12 (12 Feb 2011 20:14:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Feb 2011 20:14:52 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 12 21:14:47 2011 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.69) (envelope-from ) id 1PoLri-0003dp-Dk for guile-devel@m.gmane.org; Sat, 12 Feb 2011 21:14:46 +0100 Original-Received: from localhost ([127.0.0.1]:59970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PoLrh-0000Nd-FA for guile-devel@m.gmane.org; Sat, 12 Feb 2011 15:14:45 -0500 Original-Received: from [140.186.70.92] (port=35667 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PoLre-0000M9-8q for guile-devel@gnu.org; Sat, 12 Feb 2011 15:14:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PoLrb-0008Bm-K1 for guile-devel@gnu.org; Sat, 12 Feb 2011 15:14:41 -0500 Original-Received: from a-pb-sasl-sd.pobox.com ([64.74.157.62]:52873 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PoLrb-0008BD-BC for guile-devel@gnu.org; Sat, 12 Feb 2011 15:14:39 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5AF7D3D56; Sat, 12 Feb 2011 15:15:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=M/GJJbN5OzkpD9DTUBHObCUIWYQ=; b=gSXW6C Yzc/6f7m0wfy70uI5pj90JyKBJYTG6NIFYtx7vJFLvI7a4UYzQL7Itt8yp86mI9P QpwJqS7Ur3JsxaNafm8T3ZGkXXB/FC+GplWvotoNaeDOrfsUM3voLzbz4Uj36Aw2 H8bVqOgSi5F2QzOf5AByJ2OJs4rIfoo75n1rM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=HWAkMRCNiQtutyb90/HPvy8fTh/tVc1I CsBrhrrf+IB8zN3JhyGdaxQQBjZunSL3X4rxSaDE6R5meUBJUa1bGnlsZKbLSZmc M1/08jrt09soQZisQr8w3ZQKFBNdasMFJg9sJ5d1ARneosjG/0EpGLFhHodV+Ww0 fL1v0UScAPk= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 493583D55; Sat, 12 Feb 2011 15:15:40 -0500 (EST) Original-Received: from unquote.localdomain (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 5F8813D54; Sat, 12 Feb 2011 15:15:38 -0500 (EST) In-Reply-To: <860989.4731.qm@web114104.mail.gq1.yahoo.com> (Mark Weaver's message of "Sat, 12 Feb 2011 11:00:27 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Pobox-Relay-ID: DC8AA0FA-36E4-11E0-BACE-AF401E47CF6F-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 64.74.157.62 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:11575 Archived-At: Hi list, Mark Weaver writes in to say that his mail server crashed. The heavens conspire against us! I'm mailing the list and bccing Mark at his webmail (in case he is concerned about it leaking into the archives). So this mail is really to Mark. *** Very sorry to hear of your filesystem disasters! It never happens at a convenient time, does it? Best of luck in pulling things together again. Indeed, I was reading too fast, and I guess I swallowed the second paragraph without chewing ;) You are right, I had not considered all of the ramifications. I think that if I were fully reconciled to having values objects in our API I would have no qualms with applying your patches. As it is, it would make sense if the quotient and remainder operators were implemented in terms of the division operators, but there are performance problems there if we shunt things through value objects. I am primarily concerned with the amount of work maintaining this (excellent!) code will cause in the future. If it could be smaller while exhibiting the same functionality and good performance that would be great. Also, if we had an API which returned values in SCM* arguments would be more amenable for use in the VM. But, that's not possible now. I am just wondering if there is a sensible way to make some kind of infrastructure investment here -- a scm_c_call_with_n_values (SCM proc, size_t nargs, size_t nvals, SCM *vals, SCM arg0...) that would remove the distortion that performance concerns make on the structure of our code. Even given all this, it might still be the right thing to do to apply these patches, but I would like to hold off, pending Wednesday's 2.0 release. I am sorry that I am objecting to your code because of a problem in Guile itself, but there it is. Thanks again for your work; I hope we can reach the more perfect scheme implementation that we dream of :) And good luck with that mail server... Peace, Andy On Sat 12 Feb 2011 20:00, Mark Weaver writes: > Regarding your suggestion that I make versions of _divide that return > two values via output arguments: please re-read my post. I talked > about how I had originally started to do that, but found that it opened > up a whole new can of worms, regarding what to do when I have to > dispatch into GOOPS. Basically, all those calls to SCM_WTA_DISPATCH_2 > return a values object directly to the caller. We'd need to write > new versions of those macros that unpack the values object and return > the components via the output parameters. I'm not saying that it > can't be done, and certainly it _should_ be done, but until we have better > support for handling of multiple values from C, it's going to > be a mess. > > Best, > Mark -- http://wingolog.org/