From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Gran Newsgroups: gmane.lisp.guile.devel Subject: Re: [Guile-commits] GNU Guile branch, master, updated. release_1-9-2-164-g0d05ae7 Date: Wed, 09 Sep 2009 03:38:43 -0700 Message-ID: <1252492723.24639.44.camel@localhost.localdomain> References: <87fxaxavog.fsf@gnu.org> <1252469794.24639.20.camel@localhost.localdomain> <87vdjso97y.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1252492776 4138 80.91.229.12 (9 Sep 2009 10:39:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2009 10:39:36 +0000 (UTC) Cc: guile-devel@gnu.org To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 09 12:39:29 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MlKaE-0003Jf-Vi for guile-devel@m.gmane.org; Wed, 09 Sep 2009 12:39:27 +0200 Original-Received: from localhost ([127.0.0.1]:41587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlKaE-0001mo-7A for guile-devel@m.gmane.org; Wed, 09 Sep 2009 06:39:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlKa8-0001lr-MI for guile-devel@gnu.org; Wed, 09 Sep 2009 06:39:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlKa8-0001lf-0T for guile-devel@gnu.org; Wed, 09 Sep 2009 06:39:20 -0400 Original-Received: from [199.232.76.173] (port=34871 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlKa7-0001lc-Jw for guile-devel@gnu.org; Wed, 09 Sep 2009 06:39:19 -0400 Original-Received: from smtp110.prem.mail.sp1.yahoo.com ([98.136.44.55]:30316) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MlKa6-0003SG-Ro for guile-devel@gnu.org; Wed, 09 Sep 2009 06:39:19 -0400 Original-Received: (qmail 7860 invoked from network); 9 Sep 2009 10:39:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-Id:Mime-Version:X-Mailer:Content-Transfer-Encoding; b=Vrst9LfXFDoXDbJ+uNGbvGnxhqxJ7SLQ5XVpypxp9GujCamSIMMcht2G2Sfwa66BSKVmelVR4FGNBMF1dgTC3YyLcnBfq0nhthgjhIHxfyEQZFJR9F+6YHbbv9WrfJmFPTpsgV8/+0VIUe1eYbzVocrW8eoq0cj9l4RbhMnBh8Y= ; Original-Received: from adsl-71-130-218-93.dsl.irvnca.pacbell.net (spk121@71.130.218.93 with plain) by smtp110.prem.mail.sp1.yahoo.com with SMTP; 09 Sep 2009 03:39:17 -0700 PDT X-Yahoo-SMTP: FzNaA9iswBDuBl1BmgaIRDaP9Q-- X-YMail-OSG: kXyZqVgVM1kIOVQ.VaWdOZ6UywqmYmxECv0HVMBHsWr3dbJiTz7fvPOCpjKuCru6GxzFnHqWoa0K9oIrHgYXWzsJHEresO8Fq4Sz89XeuoTliu6nWSGaMbW8smBRVoaFg8Z8rhZ.FXHSNGUPslDsy5sdZiWYDhdtspjH6wFqrT0UsxnDXd0lG0Rgl7S10whSelGg5lnZ8qbUdj37lQv22OxqDPfF2XiM0J5_u4DmpV_l.Jw.2xEnY0YA48DFaV.N6D2w X-Yahoo-Newman-Property: ymail-3 In-Reply-To: <87vdjso97y.fsf@gnu.org> X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9290 Archived-At: On Wed, 2009-09-09 at 09:42 +0200, Ludovic Courtès wrote: > Hi, > >> > - return scm_getc (input_port); > >> > + return scm_get_byte_or_eof (input_port); > >> > >> This is actually an earlier change, but the prototype of scm_getc is now > >> different from that in 1.8. Presumably, this means that it’s not > >> source-compatible with 1.8, e.g., on platforms where > >> sizeof (int) < sizeof (scm_t_wchar), right? > > I was actually referring to the fact that 1.8 has: > > SCM_API int scm_getc (SCM port); > > whereas 1.9 has: > > SCM_API scm_t_wchar scm_getc (SCM port); > > What do you think? Sorry, I misunderstood. It is, as you say, incompatible. scm_t_wchar is scm_t_int32, not int, so 16-bit int platforms and 64-bit int platforms would notice the change. I'm fairly sure Guile doesn't run in 16-bit int platforms, but, 64-bit platforms would notice the change. I'd like to leave it scm_t_wchar == scm_t_int32. Do you think that's a problem? > >> > --- a/libguile/strings.h > >> > +++ b/libguile/strings.h > >> > @@ -111,7 +111,7 @@ SCM_API SCM scm_substring_shared (SCM str, SCM start, SCM end); > >> > SCM_API SCM scm_substring_copy (SCM str, SCM start, SCM end); > >> > SCM_API SCM scm_string_append (SCM args); > >> > > >> > -SCM_INTERNAL SCM scm_i_from_stringn (const char *str, size_t len, > >> > +SCM_API SCM scm_i_from_stringn (const char *str, size_t len, > >> > const char *encoding, > >> > scm_t_string_failed_conversion_handler > >> > handler); > >> > @@ -157,7 +157,7 @@ SCM_INTERNAL const scm_t_wchar *scm_i_string_wide_chars (SCM str); > >> > SCM_INTERNAL SCM scm_i_string_start_writing (SCM str); > >> > SCM_INTERNAL void scm_i_string_stop_writing (void); > >> > SCM_INTERNAL int scm_i_is_narrow_string (SCM str); > >> > -SCM_INTERNAL scm_t_wchar scm_i_string_ref (SCM str, size_t x); > >> > +SCM_API scm_t_wchar scm_i_string_ref (SCM str, size_t x); > >> > >> Were these changes intended? > > > > Well, one of the two of them was intended. :) > > Shouldn’t both of them remain internal given that they have an ‘_i_’ in > their name? I seemed to need to make scm_i_from_stringn into SCM_API so that I could use it in libguilereadline. Pragmatically, it is now functioning as 'SCM_API scm_from_stringn'. The gray area is if libguilereadline is philosophically 'internal' or 'external'. If libguilereadline is philosophically 'internal' it could keep the name scm_i_from_stringn, but, if that is just confusing, it should probably become scm_from_stringn. > > Until libunistring comes with Unicode regex, I think this is the best we > > can do. > > Yes, that would be neat! It is on their todo. They have header files preallocated for it. Its a big job, though. Thanks, Mike