From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Re-addition of deprecated stuff to 1.7. Date: 09 Jun 2003 21:46:17 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87llwb9gqe.fsf@zagadka.ping.de> References: <87iss97ak0.fsf@zagadka.ping.de> <3EC67BA0.2C8FF637@veritas.com> <878yslps9q.fsf@zagadka.ping.de> <3EDA5A7C.D0FB7603@veritas.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1055188370 15050 80.91.224.249 (9 Jun 2003 19:52:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2003 19:52:50 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 09 21:52:49 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19PShE-0003uc-00 for ; Mon, 09 Jun 2003 21:52:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PSgW-0002CH-IG for guile-devel@m.gmane.org; Mon, 09 Jun 2003 15:52:04 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19PSfq-0001xH-Cp for guile-devel@gnu.org; Mon, 09 Jun 2003 15:51:22 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19PSdJ-0000zs-Dg for guile-devel@gnu.org; Mon, 09 Jun 2003 15:48:56 -0400 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PSc8-0008Ty-J1 for guile-devel@gnu.org; Mon, 09 Jun 2003 15:47:32 -0400 Original-Received: from dialin.speedway42.dip223.dokom.de ([195.138.42.223] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 19PScA-0004mw-00 for guile-devel@gnu.org; Mon, 09 Jun 2003 21:47:34 +0200 Original-Received: (qmail 24794 invoked by uid 1000); 9 Jun 2003 19:46:18 -0000 Original-To: Bruce Korb In-Reply-To: <3EDA5A7C.D0FB7603@veritas.com> Original-Lines: 95 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2515 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2515 Bruce Korb writes: > Marius Vollmer wrote: > > > I'd say it is a trade-off between how much pain you are willing to > > inflict upon your clients and how much pain you are willing to suffer > > yourself. > > > > I think (and hope) it is entirely tolerable to require you clients to > > install Guile 1.6 when they want to compile your code. > > As the author of a piece of code that is relatively obscure, > it is tough enough to get it test-driven, let alone test-driven > after they have had to upgrade something else. Current distributions > are still using 1.4 (leastwise the latest Red Hat 7.x and SuSE 8.1 > use it). These releases are not even a year old yet. It *will* > be a couple of years before it is reasonable to expect all potential > clients to have 1.6. Yes, maybe. What about talking the distros into providing Guile 1.6 sooner? That would make more sense, in my view. We could provide RPMs for Red Hat, Suse, and DEBs for Debian stable. That will make it easier to retrofit ones system with Guile 1.6. > I sent some macros, tho I coded around the need to use it myself. > > > These configure snippets might be collected in a central place, maybe, > > when people are willing to maintain such a thing. > > That's what I was suggesting... Ok. So how shall we proceed? I'm don't want to make it a release-critical goal of Guile 1.8 to come with such a set of snippets unless there is more demand from 'the community'. However, the snippets can be collected in the Guile CVS repo, when people want to do that. We will have to apply all the usual FSF legal rules to them, tho: copyright must be assigned, etc. > [...] I do want to say that the compatibility glue is important. I > am now developing against 1.6. However, as much as you would like > to see 1.4 retired, the bulk of the distributions at this time have > 1.4. I need to be able to jigger what I use so it can adapt to > whatever is locally installed. So you are effectively targeting 1.4 and 1.6, not just 1.6 alone. I'm not sure what kind of compatability glue you are talking about: do you want to have a layer that makes 1.4 identical to 1.6? Or do you want a layer that fixes bugs (such as the gh_scm2newstring size_t bug) so that code that worked with 1.4 continues to work with 1.6? Neither of these two types of compatability glue makes much sense to me: for the first, it is easier to use the genuine Guile 1.6 as the 'layer'. Just package it with your code when you don't want your clients to download and install it themselves. For the second type, it is easier to just stick with Guile 1.4, which should be available already on your clients system, as you say. > By the time the bulk of installations are running 1.6, you'll be > shipping 1.8 and using the same arguments. Yes. And I sill think they are sensible arguments. > [...] OTOH, when you retire ``scm_port'' you could also add: > > #if (THE_LAST_GUILE_VERSION_I_KNEW_ABOUT < GUILE_VERSION_1_6) > # define scm_port scm_t_port > #endif > > and delete that code only after 1.6 has been in the major distros > for a couple of years. Yes, we are doing this now (kind of) and are being more careful than we have been with 1.6. See the "Handling of Deprecated Features" section in the README. Incidentally, "scm_port" is available with Guile 1.6, but I see that you want to have "scm_t_port" with 1.4. That's a strange thing to do, in my view: you can't get the 'goodness' of 1.6 from 1.4. You might create the illusion in simple cases like scm_port, but this wont work in general. The result is code that is written is then a, in your own words: > The Guile version I understand is a mix of 1.4 and 1.6 'cuz I'm > transitioning. Coding for such a mixed API is not on the path of least pain, I'd say. > > It is of course good practice to minimize the needed changes, > > I'm sure you do your best. One's best cannot ever be perfect. But we are getting better! :-) -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel