From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.bugs Subject: Re: [Bug-autogen] test failure with guile-2.0.2 Date: Thu, 14 Jul 2011 11:01:11 +0200 Message-ID: <87vcv5kzhk.fsf@pobox.com> References: <20110710.001131.2114114687665811411.pipping@lavabit.com> <4E1AFA72.2050803@gnu.org> <871uxud0s7.fsf@pobox.com> <4E1D95A0.60504@gnu.org> <87oc0yb8mh.fsf@pobox.com> <4E1DB59B.9070700@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1310644437 17344 80.91.229.12 (14 Jul 2011 11:53:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2011 11:53:57 +0000 (UTC) Cc: bug-guile@gnu.org, bug-autogen@gnu.org, Elias Pipping To: Bruce Korb Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Jul 14 13:53:52 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QhKUH-0005wt-T5 for guile-bugs@m.gmane.org; Thu, 14 Jul 2011 13:53:50 +0200 Original-Received: from localhost ([::1]:53947 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhKUG-0005Ue-W3 for guile-bugs@m.gmane.org; Thu, 14 Jul 2011 07:53:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhKTx-0005UQ-1N for bug-guile@gnu.org; Thu, 14 Jul 2011 07:53:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QhKTs-0003l5-6L for bug-guile@gnu.org; Thu, 14 Jul 2011 07:53:28 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:52527 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhKTa-0003iA-Bt; Thu, 14 Jul 2011 07:53:06 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E98C062CA; Thu, 14 Jul 2011 07:53:05 -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; s=sasl; bh=ZBwdhPrqTQBaPGK6+a3VI4G45HM=; b=juDuVC +zeob55i/9cDbvYV+E/HPiMw7R9zNlUR1MYcgll6mdHxy0b3pmxJuEqKbLybFSms aZgaczCR9tGU5PKogOyNESmtzNdXnmvJuxiSlfVnqBWtZAC1AA2TIz5pcICRBvxy 5KYIGtzWbcMqdvDy928+fMugFGX4joh64UXX0= 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=gIdWqLZeD0GlIEFEvPZJxG82EovLSVl8 OCS4pH7jRuvbXYDNYZv5LWM4O7ENebcUUwQ40ZPhz2KMnq7rOdmYE+/nSUuOn5RT FvdfymqaAhK2FVOrzZTQwU+TjuMmTjZ64u1Xtdj1FuAwqRbe60q6cW7VDwRJWw2i bg/E0ML8HUc= 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 DFECB62C9; Thu, 14 Jul 2011 07:53:00 -0400 (EDT) Original-Received: from badger (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 22F6562C6; Thu, 14 Jul 2011 07:52:50 -0400 (EDT) In-Reply-To: <4E1DB59B.9070700@gnu.org> (Bruce Korb's message of "Wed, 13 Jul 2011 08:11:23 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-Pobox-Relay-ID: CD49AC10-AE0F-11E0-B2E8-B797DE995924-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:5731 Archived-At: Hi Bruce, On Wed 13 Jul 2011 17:11, Bruce Korb writes: > On 07/13/11 06:41, Andy Wingo wrote: >> the new interface name is libguile-2.0.so. > > Well, yes, but for source distributions, it gets compiled and linked > against whatever the current platform's default Guile happens to be. I would like to avoid this circumstance in the future, while still preserving Guile's ability to change. Hopefully whenever you decide that you can stop supporting Guile 1.6, as we have, then you can switch to use pkg-config. This will allow you to specify the versions of Guile that you support, at build-time, *and choose them* from among a number of installed Guile versions. This way, you only deal with changes in Guile 2.2 *when you choose* to upgrade to Guile 2.2. Presumably at that point you read the NEWS as well :-) But, with the current guile-config situation, that's not the case. You end up dealing with changes in Guile when you're trying to do something else, as now. But it's bugs versus bugs, right? What did you expect us to do, deprecate scm_from_locale_string because in 1.8 it could be treated as a byte array, after introducing it in 1.8? > New name, please. We'll try harder in the future. But we cannot change the fact that scm_from_locale_string does decode its argument. One thing we might be able to do is Mark Weaver's "permissive" string trick using the reserved unicode codepoints. That code doesn't exist yet though. > #if GUILE_VERSION < 107000 > # define AG_SCM_BOOL_P(_b) SCM_BOOLP(_b) > # define AG_SCM_CHAR(_c) gh_scm2char(_c) IMO, this is not the way to do deprecation. The way to go is to use the new names, and #define implementations for older Guile. That way your source is cleaner, and you get deprecation messages when current functions are deprecated. So here you should use scm_is_bool and SCM_CHAR. > # define AG_SCM_CHARS(_s) SCM_CHARS(_s) [...] > #elif GUILE_VERSION < 201000 > # define AG_SCM_CHARS(_s) scm_i_string_chars(_s) This is totally incorrect, and a bit dangerous. It won't work if you have a wide string. The "_i_" in the name is for "internal". From the NEWS from 1.8.0, from February 2006, notes: ** The macros SCM_STRINGP, SCM_STRING_CHARS, SCM_STRING_LENGTH, SCM_SYMBOL_CHARS, and SCM_SYMBOL_LENGTH have been deprecated. They export too many assumptions about the implementation of strings and symbols that are no longer true in the presence of mutation-sharing substrings and when Guile switches to some form of Unicode. When working with strings, it is often best to use the normal string functions provided by Guile, such as scm_c_string_ref, scm_c_string_set_x, scm_string_append, etc. Be sure to look in the manual since many more such functions are now provided than previously. When you want to convert a SCM string to a C string, use the scm_to_locale_string function or similar instead. For symbols, use scm_symbol_to_string and then work with that string. Because of the new string representation, scm_symbol_to_string does not need to copy and is thus quite efficient. You'll be much less surprised at things if you read the NEWS when new major versions are released :-) Finally, as I think we have discussed already all of the relevant aspects of this situation, we need to move on. The easiest thing to do is for you to put in a couple of #defines for scm_{from,to}_latin1_string. Then we can go back to building GNU! Regards, Andy -- http://wingolog.org/