From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Gran Newsgroups: gmane.lisp.guile.bugs,gmane.lisp.guile.devel Subject: Re: UTF-8 regression in guile 1.9.5 Date: Sun, 10 Jan 2010 14:00:31 -0800 (PST) Message-ID: <67395.2223.qm@web37901.mail.mud.yahoo.com> References: <3ae3aa420912061043y12a33f27ia3d2c298812ee358@mail.gmail.com> <437145.81403.qm@web37905.mail.mud.yahoo.com> <3ae3aa420912061133r3d2fb5b4w2b3ea31f3d05e701@mail.gmail.com> <600066.28581.qm@web37908.mail.mud.yahoo.com> <3ae3aa420912061243nfb7f54cv1fd14950849b67fe@mail.gmail.com> <188729.99650.qm@web37904.mail.mud.yahoo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1263160851 13720 80.91.229.12 (10 Jan 2010 22:00:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2010 22:00:51 +0000 (UTC) Cc: bug-guile@gnu.org, linasvepstas@gmail.com, Guile Development To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Jan 10 23:00:44 2010 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NU5pz-000742-Ez for guile-bugs@m.gmane.org; Sun, 10 Jan 2010 23:00:43 +0100 Original-Received: from localhost ([127.0.0.1]:45214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NU5pz-0003cP-Ug for guile-bugs@m.gmane.org; Sun, 10 Jan 2010 17:00:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NU5pu-0003ar-D5 for bug-guile@gnu.org; Sun, 10 Jan 2010 17:00:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NU5pq-0003YQ-P3 for bug-guile@gnu.org; Sun, 10 Jan 2010 17:00:38 -0500 Original-Received: from [199.232.76.173] (port=46243 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NU5pq-0003YA-GL for bug-guile@gnu.org; Sun, 10 Jan 2010 17:00:34 -0500 Original-Received: from web37901.mail.mud.yahoo.com ([209.191.91.163]:47455) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NU5pq-0006Cd-00 for bug-guile@gnu.org; Sun, 10 Jan 2010 17:00:34 -0500 Original-Received: (qmail 4174 invoked by uid 60001); 10 Jan 2010 22:00:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263160832; bh=VV1SouBk1iZLkeCWIWqi9MiUWTsMgKxENq9/YnMxIgA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nFA2vFReAVy+TRoRMbNBMin6Kr74PgOIEqqSz7dZHbaJt+ouKB8OPA3y0KyWAiOo9W60i9+mDN9fYqIsn8mVqsdMWy9KKMLUmlI73mxOn9lhfaiMSLwie5hCOi0NJMBkhWPUoYz8AhWnz9ksvoRWlqO8rCNHhoA68A5jcufU/KA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HRVDB4i0Cj4tDpCU90fpsGyy9KaFhsmWCBT1Id1ln1RVwONAJVfHcUHjt85v3Hu7ZgvvfRaRrj5xiNyAtt6mG7E4PrNvQrsGxCSxcJ9f617xPq5iOfCRSJ5qatcKxB7hXC8Z+7/MX6WhkCTxc81LHZJ05Kv5QkBxlq7bDRIDcwo=; X-YMail-OSG: yzkrzToVM1lD8tt4YZxJCoB_l6AE9l0ViMPdFb7d8aI_E93qe61w50MRxgkuQaJ1kcNnm2ZKyzvv2Zh3mqvMUzmUwgJ5lckXB9usGm9.1EAlYegFpK5TWPPMwfb89eTgJD0gs6.UZXyjoXhOzfFSjoN3DK3uZ1IancVdtu4PwdgUwrKDqJypkPLWYxh6ZHzuht6lQ_ZNJWyGEX9Ntpkmp3v5Cf5asrcNcLoJo_w6DwJmiEsK6bPxz9msSPfZ_Vpg2_sEdNu4OwpV_MoWpnrRDmochNnJQuwt1Kf5U.rGTk1GX0Z8IH1rfwYG53lOUxl8vTYIJa8XmqrHHV7e6NaHRy47O3DchWnN8ngVQbBk Original-Received: from [71.140.100.71] by web37901.mail.mud.yahoo.com via HTTP; Sun, 10 Jan 2010 14:00:31 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:4441 gmane.lisp.guile.devel:9845 Archived-At: > From: Andy Wingo > Hi, > > Reviving an old thread... > > > I think I prefer that the coder take the responsibility of calling > > setlocale, but, I only think that because it is how C works. I'm used > > to that convention. > > I would still prefer ponies and magic, but I realized: if we do a > setlocale(LC_ALL, "") at the beginning, might that not change e.g. the > floating point format, or some other locale-related variable, which > would make Guile modules unreadable, or otherwise semantically different > or invalid? > > I'm asking because I ran into this bug now: > > scheme@(guile-user)> ,pr (resolve-module '(gnome gtk)) > Throw to key `wrong-type-arg' with args `("procedure-name" "Wrong type > argument in position ~A: ~S" (1 #) > (#))'. > Entering the debugger. Type `bt' for a backtrace or `c' to continue. > 0 debug> bt > In current input: > : 13 ERROR: cannot convert to output locale "NONE": > ""dynamic-wind"" > > So I guess we need a special case for NONE there, or something. I really > don't understand i18n/l10n. A LOCALE=NONE is the same as setting locale to any undefined value,e.g. LOCALE=martian_mars. There isn't a locale called 'none', so the system can provide no clues on how I/O, date format, etc, should be done. All programs are supposed to start with locale="C", so I guess the NONE locale is being set explicitly at some point. On my box, I can't (setlocale LC_ALL "NONE") since I don't have a NONE locale. So, the fact that locale=NONE seems like a bug to me. For Guile string conversion, if locale=NONE has some non-buggy meaning, I'd probably suggest making NONE the same as UTF-8. We can do whatever we want, since the result of the operation of conversion into NONE is undefined. But as far as the greater question of the side effects of setting locale early on startup... The parsing of any source code files after locale is set will be done in that context. I don't think it would do anything unexpected. The reader and the port routines tend to do their own parsing, and don't tend to rely on libc locale-specific routines. Even so, it would take some auditing to prove that there would be no effect. If you were to set the locale in Guile, you would need to add a condition to catch if the current LANG envvar isn't set to a valid locale so you can fall back to the "C" locale. -Mike Gran