From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bruce Korb Newsgroups: gmane.lisp.guile.bugs Subject: Re: [Bug-autogen] test failure with guile-2.0.2 Date: Wed, 13 Jul 2011 05:54:56 -0700 Message-ID: <4E1D95A0.60504__21732.8103412457$1310562131$gmane$org@gnu.org> References: <20110710.001131.2114114687665811411.pipping@lavabit.com> <4E1AFA72.2050803@gnu.org> <871uxud0s7.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1310562131 12514 80.91.229.12 (13 Jul 2011 13:02:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 13:02:11 +0000 (UTC) Cc: bug-guile@gnu.org, bug-autogen@gnu.org, Elias Pipping To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Jul 13 15:02:07 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 1Qgz4p-0007o7-0r for guile-bugs@m.gmane.org; Wed, 13 Jul 2011 15:02:07 +0200 Original-Received: from localhost ([::1]:51622 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qgz4n-0006Zi-DG for guile-bugs@m.gmane.org; Wed, 13 Jul 2011 09:02:05 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qgyy2-0005BS-0K for bug-guile@gnu.org; Wed, 13 Jul 2011 08:55:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qgyxv-0005eT-Mq for bug-guile@gnu.org; Wed, 13 Jul 2011 08:55:05 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:56146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qgyxv-0005eJ-DS; Wed, 13 Jul 2011 08:54:59 -0400 Original-Received: from adsl-75-0-186-148.dsl.pltn13.sbcglobal.net ([75.0.186.148]:52577 helo=[10.0.0.2]) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Qgyxv-0000N3-1P; Wed, 13 Jul 2011 08:54:59 -0400 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 In-Reply-To: <871uxud0s7.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:5726 Archived-At: Hi Andy, On 07/13/11 01:48, Andy Wingo wrote: > I'm not sure what the bug report here is. I'm getting a lot of angst > though :-) :) Not angst so much as mild irritation, some of it stirred up residuals from the 1.4 -> 1.6 -> 1.8 transitions. I was only just recently able to drop Guile 1.4 support and it will be a couple more before 1.6 goes away. My feint hopes of getting rid of the versioned Guile glue layer are now dashed: > On Mon 11 Jul 2011 15:28, Bruce Korb writes: > >> The intent is that I have several functions: raw-shell-str, shell-str, >> c-string and kr-string each of which produces precisely the same byte >> sequence as their argument for the intended target environment. > > But if I understand you correctly, here you would like to manipulate > *byte sequences* as strings. Strings are logically character sequences, > so you need to choose a mapping that preserves the identity of bytes > with characters. That mapping is latin-1. "latin1" is an alias for "ascii byte strings"? Anyway: > In the NEWS for 2.0.0: > > ** New procedures: `scm_to_stringn', `scm_from_stringn' > ** New procedures: scm_{to,from}_{utf8,latin1}_symbol{n,} > ** New procedures: scm_{to,from}_{utf8,utf32,latin1}_string{n,} > > These new procedures convert to and from string representations in > particular encodings. > > Users should continue to use locale encoding for user input, user > output, or interacting with the C library. This means that *THE SEMANTICS HAVE CHANGED* for these functions. New semantics should always imply a new interface name. This is a new interface. > Use the Latin-1 functions for ASCII, and for literals in source code. The latin-1 functions should be the preferred spelling for the old "locale" functions. The new locale functions need a new spelling. It is confusing to have old functions performing new tricks. The old name needs a compatibility grace period. > It sounds like you want scm_{to,from}_latin1_string. On Guile 1.8 and > before, you can #define this to scm_{to,from}_locale_string, as earlier > versions of Guile did not have the needed string encoding support. Actually, I said what I meant. I want byte array functions where Guile isn't thinking that it knows better than I do what bit values ought to be in each byte. It is an array of byte values each of which is in the range of 1 through 255 with the last value is always zero (0). Thank you. Regards, Bruce