From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bruce Korb Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile: What's wrong with this? Date: Tue, 03 Jan 2012 16:55:50 -0800 Message-ID: <4F03A396.8080404@gnu.org> References: <4F027F35.5020001@gmail.com> <1325603029.22166.YahooMailNeo@web37906.mail.mud.yahoo.com> <4F032C41.3070300@gmail.com> <87mxa4ifux.fsf@gnu.org> <4F038BF4.1070200@gnu.org> <87boqkgy3x.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1325638563 24572 80.91.229.12 (4 Jan 2012 00:56:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 00:56:03 +0000 (UTC) Cc: guile-devel@gnu.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jan 04 01:55:59 2012 Return-path: Envelope-to: guile-devel@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 1RiF95-0001I2-Gg for guile-devel@m.gmane.org; Wed, 04 Jan 2012 01:55:59 +0100 Original-Received: from localhost ([::1]:34546 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiF94-0005fA-7A for guile-devel@m.gmane.org; Tue, 03 Jan 2012 19:55:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiF91-0005eu-H1 for guile-devel@gnu.org; Tue, 03 Jan 2012 19:55:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiF90-0004ht-66 for guile-devel@gnu.org; Tue, 03 Jan 2012 19:55:55 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:33866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiF90-0004hp-3O for guile-devel@gnu.org; Tue, 03 Jan 2012 19:55:54 -0500 Original-Received: from adsl-75-0-189-83.dsl.pltn13.sbcglobal.net ([75.0.189.83]:45975 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 1RiF8y-0001hZ-Vi; Tue, 03 Jan 2012 19:55:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 In-Reply-To: <87boqkgy3x.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:13252 Archived-At: On 01/03/12 15:33, Ludovic Courtès wrote: > Could you point me to the affected code? What would you think of using > string-copy as I suggested? The disadvantage is that you need to modify > your code, but hopefully that can be automated with a sed script or so; > the advantage is that it would work with all versions of Guile. The disadvantage is that I know I have "clients" that have rolled their own templates, presumably by copy-and-edit processes that will invariably include (define var "string") syntax. Likely a better approach is to re-define the "define" function to my own C code and call the proper scm_whathaveyou functions under the covers. I'm sorry about being irritable. This is the third problem with 2.x. First a pre-defined value disappeared. A very minor nuisance. Then it turned out that the string functions would now clear the high order bit on strings, so they are no longer byte arrays and there is no replacement but to roll my own. I stopped supporting byte arrays. A noticable nuisance. Now it turns out that the conventional, ordinary way of creating a string variable yields a read-only string. Ouch. So I am cranky and sorry about being so. So I guess that's my fix. Write another function dependent upon Guile internals, much like scm_c_eval_string_from_file_line(), by copying scm_define() code, checking for a string value and copying that string -- if it is read-only? Should I check for that? What about "set!"? Should I check for a read-only value there, too? I do confess it feels a little bit like unraveling something.....It is scary.