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: Compiled load path issues Date: Tue, 20 Oct 2009 20:59:41 +0200 Message-ID: References: <871vl090k6.fsf@gnu.org> <87y6n6mpw1.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1256065232 27100 80.91.229.12 (20 Oct 2009 19:00:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Oct 2009 19:00:32 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 20 21:00:21 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 1N0JwS-00013d-Lo for guile-devel@m.gmane.org; Tue, 20 Oct 2009 21:00:21 +0200 Original-Received: from localhost ([127.0.0.1]:53857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0JwS-0006O4-7H for guile-devel@m.gmane.org; Tue, 20 Oct 2009 15:00:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0JvY-000699-TZ for guile-devel@gnu.org; Tue, 20 Oct 2009 14:59:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0JvU-00066e-4c for guile-devel@gnu.org; Tue, 20 Oct 2009 14:59:24 -0400 Original-Received: from [199.232.76.173] (port=36069 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0JvU-00066V-1F for guile-devel@gnu.org; Tue, 20 Oct 2009 14:59:20 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:52233 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N0JvO-0006TV-1S; Tue, 20 Oct 2009 14:59:14 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8F4F060460; Tue, 20 Oct 2009 14:59:13 -0400 (EDT) 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:content-transfer-encoding; s=sasl; bh=ZRZr7R5+t/lG yRCeyFfXnLYmJKw=; b=TVacZL3MBPiOzaf3SblyQV6UBH+7HZfXc5Nlg1yDn1ko ton4cAKA0E8Dt7WEJwR6ZrbGBMCbebIpbWbZOKjIS8iBIzTgKeRZfJuAywBkJjyh dZpgnhfCAx3lNGwRlke0U/6cbmxkjUkKa7rolYehODD+Lsnhc0/k2RjQ2PLNUY8= 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:content-transfer-encoding; q=dns; s=sasl; b=NpnUH4 Jv9uUZmE29oNXfFh+E18hYBEVsunObczf1KGZTfG4kUQD5CJtbmT1mbVjXPd0HuZ d3LFCjhNaZVH4f5vsAv1IVzF/KSH3lNYxNuSk4MwBukjpEv6lhYG/wf0NpmsIzG3 2N0PUmY9nR4ZQWL+drSLxNGbw0Z43uKpneF1Q= Original-Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7E8B46045F; Tue, 20 Oct 2009 14:59:12 -0400 (EDT) Original-Received: from unquote (unknown [83.34.240.150]) (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 95A096045E; Tue, 20 Oct 2009 14:59:10 -0400 (EDT) In-Reply-To: <87y6n6mpw1.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 20 Oct 2009 10:27:26 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: A7CB61A6-BDAA-11DE-803B-1B12EE7EF46B-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:9538 Archived-At: Hello ludovic, On Tue 20 Oct 2009 10:27, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Andy Wingo writes: > >> On Sun 18 Oct 2009 17:36, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > > [...] > >>> Andy: can you comment? What was the idea behind >>> =E2=80=98%load-compiled-path=E2=80=99? >> >> The idea is that given that the compiled files are >> architecture-dependent, > > In theory, we could interpret the =E2=80=98.go=E2=80=99 cookie and byte-s= wap things if > needed... In theory yes. In practice we map things read-only so they can be cached and not copied, and we'd have to instrument individual VM ops with checks based on the current objcode, flags for the objcode to say their format, etc. I really think it's too complicated. If this is really the way we want to go, we should give up on having endian-specific bytecode -- which is a bigger task, not to mention the tail wagging the dog. >> that they should go in $libdir instead of $datadir. We can add >> $libdir, but I don't think it's a good idea -- not only for reasons of >> excessive stat, but because I don't think we should be putting >> binaries in with installed source. > > By now people may have started to update their packages to run > =E2=80=9Cguile-tools compile=E2=80=9D and install =E2=80=98.go=E2=80=99 f= iles, so we really need to get > this issue settled. > > I=E2=80=99m in favor of =E2=80=98.go=E2=80=99 alongside =E2=80=98.scm=E2= =80=99: that=E2=80=99s what happens with > .elc/.el and .pyc/.py and it had been the plan from 1.9.0 until > recently. For python, pyc files are in $libdir, for exactly this reason. Plus, you might have some source files that you want to compile with multiple versions of Guile. I don't think we should be encouraging this. >>> Besides, =E2=80=98scm_search_path=C2=A0()=E2=80=99 was changed incompat= ibly compared to 1.8 >>> in 22f4ee48822db5e30df3abf9a11b6066f2bab9d3. I=E2=80=99m wary about su= ch >>> incompatibilities and would like it if we could (1) list them, and >>> (2)=C2=A0avoid them unless we really really can=E2=80=99t think of any = other way. In >>> this particular case, do you have an idea on how to avoid it? >> >> I don't really know. I'm sure it could be worked around somehow, but >> it's not very fun work. > > It=E2=80=99s not, but there=E2=80=99s a fair amount of not very fun work = in this vain to > be done by 2.0. :-) > > I think we must pay close attention to backwards compatibility, at least > to honor long time promises > (http://lists.gnu.org/archive/html/guile-devel/2003-02/msg00074.html). So for the list, we did have a chat about this on IRC. We both agree that we should not needlessly introduce incompatibilities, especially on the C level. This is especially a problem because e.g. gnucash, configuring as it is with guile.m4 and guile-config, will simply pick up the new version of Guile when it's installed -- which is like upgrading when you didn't choose to. Gnucash should only have to be concerned with Guile when it chooses to. For that reason we also think that Guile should be parallel-installable, at least on the library level. That means that we should have the version in the library name, and the version in the include path; so pkg-config --cflags guile-2.0 will say e.g. -I/usr/include/guile-2.0, and that pkg-config --libs guile-2.0 will be e.g. -lguile-2-0, or something. A more detailed manifesto is here: http://www106.pair.com/rhp/parallel.html Removing barriers to new version adoption The big benefit of parallel installation is that you remove the reason why people are reluctant to upgrade to a new version of Foo, because upgrading to Foo 5 has no effect on users of Foo 4. This means that the packages in [the distro] can be upgraded by their upstream maintainers, one at a time. It means that GNOME packages can upgrade to Foo 5 one at a time. It means that if I use a text editor dependent on Foo 4, but want my package to use Foo 5, I can do that since I can install both versions of Foo at the same time. In short, parallel install nukes the chicken and egg problem, and it saves everyone a bunch of time and energy. (A side effect: suddenly you have far more freedom to break backward compatibility; your new incompatible version is in fact a different library, not the same library. So if you need to clean up a big nest of cruft, no big deal. No one is forced to upgrade until they have time to deal with the breakage.) That last paragraph is key for me. Sure, we need to make well-thought-out changes -- but our current policy of very extended C-level compatibility is very, very limiting, and a big energy drain. If we think we need to change a function interface, well, we just change it, and document the change as well -- perhaps even with a Coccinelle[0] patch. So whenever Lilypond realizes that Guile 2.2 gives them native Scheme compilation, but changes a couple of functions, they can weigh their choice, and if they decide to upgrade, they know what to do. [0] http://lwn.net/Articles/315686/ Anyway, comments welcome. Ludovic let me know if this actually represents what you think, or if I'm just putting bytes in your mouth :) Cheers, Andy --=20 http://wingolog.org/