* Text collation
@ 2006-09-19 9:23 Ludovic Courtès
2006-09-19 22:38 ` Kevin Ryde
0 siblings, 1 reply; 46+ messages in thread
From: Ludovic Courtès @ 2006-09-19 9:23 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]
Hi,
Guile doesn't provide any locale-dependent string comparison primitive.
`string<?' et al., from SRFI-13 (also found in R5.91RS), are required to
be locale-independent:
These procedures are the lexicographic extensions to strings of the
corresponding orderings on characters. For example, string< is the
lexicographic ordering on strings induced by the ordering char<? on
characters.
[...]
Comparison is simply done on individual code-points of the
string. True text collation is not handled by this SRFI.
R5.91RS, about `char<?' et al., adds:
These procedures impose a total ordering on the set of characters
according to their scalar values.
Thus, for proper locale-dependent "text collation", we need a separate
API. The patch below provides preliminary support for this. Here is a
sample session showing how the API can be used:
guile> (define l (make-locale LC_COLLATE_MASK "fr_FR"))
guile> l
#<locale 300a74d0>
guile> (string-locale<? "été" "hiver") ;; using the "C" locale
#f
guile> (string-locale<? "été" "hiver" l)
#t
guile> (char-locale<? #\é #\h) ;; using the "C" locale
#f
guile> (char-locale<? #\é #\h l)
#t
guile> (setlocale LC_COLLATE "fr_FR")
"fr_FR"
guile> (string-locale<? "été" "hiver") ;; using the "fr_FR" locale
#t
The cool thing is that it's a "clean" API in that the locale settings
can be passed explicitly as a third parameter. The (potentially)
controversial part is that this wraps a non-standard GNU extension.
I don't think this should be seen as a problem, first because this GNU
extension can be emulated on non-GNU platforms by controlling
invocations of `setlocale' (via a mutex) and by using that to create
"critical locale sections" within the `-locale<?' functions:
/* Save the current locale settings and install LOCALE_SETTINGS. */
scm_being_locked_locale_section (locale_settings);
result = strcoll (c_s1, c_s2);
/* ... */
/* Restore the previous locale settings. */
scm_end_locked_locale_section ();
Emulation of the locale category mask that is passed to `make-locale'
may turn out to be quite inelegant, but it can be implemented in terms
of `setlocale ()' (as many calls as bits set in the mask).
Second, it is likely that this or a similar API will be adopted by OSes
and may eventually be standardized. The C++ standard already includes a
similar locale API (ISO C++ 14882, see the `locale_classes.h' header
that ships with GCC).
The GNU C library also provides `strcasecmp_l ()' which would be nice to
have but since this would be hard or even impossible to "emulate" on
other platforms, it may be preferable not to include it at the moment.
If all this sounds like a reasonable plan to you, then I can implement
locked locale sections (for non-GNU platforms), augment the docs, and
eventually merge it in both 1.8 and HEAD.
Thanks,
Ludovic.
PS: I would be happier if this was part of an `(ice-9 i18n)' module but
since it's already too late for `gettext', `bindtextdomain' and
friends to go there, maybe we should just keep using the root
module...
[-- Attachment #2: The patch --]
[-- Type: text/plain, Size: 8378 bytes --]
--- orig/configure.in
+++ mod/configure.in
@@ -599,8 +599,9 @@
# stat64 - SuS largefile stuff, not on old systems
# sysconf - not on old systems
# _NSGetEnviron - Darwin specific
+# strcoll_l, newlocale - GNU extensions (glibc)
#
-AC_CHECK_FUNCS([DINFINITY DQNAN ctermid fesetround ftime fchown getcwd geteuid gettimeofday gmtime_r ioctl lstat mkdir mknod nice readdir_r readlink rename rmdir select setegid seteuid setlocale setpgid setsid sigaction siginterrupt stat64 strftime strptime symlink sync sysconf tcgetpgrp tcsetpgrp times uname waitpid strdup system usleep atexit on_exit chown link fcntl ttyname getpwent getgrent kill getppid getpgrp fork setitimer getitimer strchr strcmp index bcopy memcpy rindex unsetenv _NSGetEnviron])
+AC_CHECK_FUNCS([DINFINITY DQNAN ctermid fesetround ftime fchown getcwd geteuid gettimeofday gmtime_r ioctl lstat mkdir mknod nice readdir_r readlink rename rmdir select setegid seteuid setlocale setpgid setsid sigaction siginterrupt stat64 strftime strptime symlink sync sysconf tcgetpgrp tcsetpgrp times uname waitpid strdup system usleep atexit on_exit chown link fcntl ttyname getpwent getgrent kill getppid getpgrp fork setitimer getitimer strchr strcmp index bcopy memcpy rindex unsetenv _NSGetEnviron strcoll strcoll_l newlocale])
# Reasons for testing:
# netdb.h - not in mingw
--- orig/libguile/i18n.c
+++ mod/libguile/i18n.c
@@ -15,6 +15,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#define _GNU_SOURCE /* Ask for glibc's `newlocale' API */
#if HAVE_CONFIG_H
# include <config.h>
@@ -24,10 +25,13 @@
#include "libguile/feature.h"
#include "libguile/i18n.h"
#include "libguile/strings.h"
+#include "libguile/chars.h"
#include "libguile/dynwind.h"
+#include "libguile/validate.h"
#include "gettext.h"
#include <locale.h>
+#include <string.h> /* `strcoll ()' */
int
@@ -312,10 +316,206 @@
}
#undef FUNC_NAME
-void
+\f
+/* Locale objects, string and character collation. */
+
+SCM_SMOB (scm_tc16_locale_smob_type, "locale", 0);
+
+SCM_SMOB_FREE (scm_tc16_locale_smob_type, smob_locale_free, locale)
+{
+#ifdef __GNU_LIBRARY__
+ freelocale ((locale_t)SCM_SMOB_DATA (locale));
+#endif
+
+ return 0;
+}
+
+#ifndef __GNU_LIBRARY__
+
+/* Provide the locale category masks as found in glibc (copied from
+ <locale.h> as found in glibc 2.3.6). */
+
+# define LC_CTYPE_MASK (1 << LC_CTYPE)
+# define LC_NUMERIC_MASK (1 << LC_NUMERIC)
+# define LC_TIME_MASK (1 << LC_TIME)
+# define LC_COLLATE_MASK (1 << LC_COLLATE)
+# define LC_MONETARY_MASK (1 << LC_MONETARY)
+# define LC_MESSAGES_MASK (1 << LC_MESSAGES)
+# define LC_PAPER_MASK (1 << LC_PAPER)
+# define LC_NAME_MASK (1 << LC_NAME)
+# define LC_ADDRESS_MASK (1 << LC_ADDRESS)
+# define LC_TELEPHONE_MASK (1 << LC_TELEPHONE)
+# define LC_MEASUREMENT_MASK (1 << LC_MEASUREMENT)
+# define LC_IDENTIFICATION_MASK (1 << LC_IDENTIFICATION)
+# define LC_ALL_MASK (LC_CTYPE_MASK \
+ | LC_NUMERIC_MASK \
+ | LC_TIME_MASK \
+ | LC_COLLATE_MASK \
+ | LC_MONETARY_MASK \
+ | LC_MESSAGES_MASK \
+ | LC_PAPER_MASK \
+ | LC_NAME_MASK \
+ | LC_ADDRESS_MASK \
+ | LC_TELEPHONE_MASK \
+ | LC_MEASUREMENT_MASK \
+ | LC_IDENTIFICATION_MASK \
+ )
+
+#endif
+
+
+SCM_DEFINE (scm_make_locale, "make-locale", 2, 1, 0,
+ (SCM category_mask, SCM locale_name, SCM base_locale),
+ "Return a reference to a data structure representing a set of "
+ "locale datasets. Unlike for the @var{category} parameter for "
+ "@code{setlocale}, the @var{category_mask} parameter here uses "
+ "a single bit for each category, made by OR'ing together "
+ "@code{LC_*_MASK} bits.")
+#define FUNC_NAME s_scm_make_locale
+{
+#ifdef __GNU_LIBRARY__
+ SCM locale;
+ int c_category_mask;
+ char *c_locale_name;
+ locale_t c_base_locale, c_locale;
+
+ SCM_VALIDATE_INT_COPY (1, category_mask, c_category_mask);
+ SCM_VALIDATE_STRING (2, locale_name);
+ c_locale_name = scm_to_locale_string (locale_name);
+
+ if (base_locale != SCM_UNDEFINED)
+ {
+ SCM_VALIDATE_SMOB (3, base_locale, locale_smob_type);
+ c_base_locale = (locale_t)SCM_SMOB_DATA (base_locale);
+ }
+ else
+ c_base_locale = NULL;
+
+ c_locale = newlocale (c_category_mask, c_locale_name, c_base_locale);
+ free (c_base_locale);
+
+ if (!c_locale)
+ locale = SCM_BOOL_F;
+ else
+ SCM_NEWSMOB (locale, scm_tc16_locale_smob_type, c_locale);
+
+ return locale;
+#else
+ /* FIXME: Handle this situation, for instance:
+ SCM_RETURN_NEWSMOB (scm_tc16_locale_smob_type,
+ scm_list_3 (category_mask, locale_name,
+ base_locale)); */
+ return SCM_BOOL_F;
+#endif
+}
+#undef FUNC_NAME
+
+
+/* Compare null-terminated strings C_S1 and C_S2 according to LOCALE. Return
+ an integer whose sign is the same as the difference between C_S1 and
+ C_S2. */
+static inline int
+compare_strings (const char *c_s1, const char *c_s2, SCM locale,
+ const char *func_name)
+#define FUNC_NAME func_name
+{
+#ifdef __GNU_LIBRARY__
+ locale_t c_locale;
+#endif
+ int result;
+
+#ifdef __GNU_LIBRARY__
+ if (locale != SCM_UNDEFINED)
+ {
+ SCM_VALIDATE_SMOB (3, locale, locale_smob_type);
+ c_locale = (locale_t)SCM_SMOB_DATA (locale);
+ }
+ else
+ c_locale = NULL;
+
+ if (c_locale)
+ result = strcoll_l (c_s1, c_s2, c_locale);
+ else
+#endif
+
+#if HAVE_STRCOLL
+ result = strcoll (c_s1, c_s2);
+#else
+ result = strcmp (c_s1, c_s2);
+#endif
+
+ return result;
+}
+#undef FUNC_NAME
+
+
+SCM_DEFINE (scm_string_locale_lt, "string-locale<?", 2, 1, 0,
+ (SCM s1, SCM s2, SCM locale),
+ "Compare strings @var{s1} and @var{s2} in a locale-dependent way."
+ "If @var{locale} is provided, it should be locale object (as "
+ "returned by @code{make-locale}) and will be used to perform the "
+ "comparison; otherwise, the current system locale is used.")
+#define FUNC_NAME s_scm_string_locale_lt
+{
+ int result;
+ const char *c_s1, *c_s2;
+
+ SCM_VALIDATE_STRING (1, s1);
+ SCM_VALIDATE_STRING (2, s2);
+
+ c_s1 = scm_i_string_chars (s1);
+ c_s2 = scm_i_string_chars (s2);
+
+ result = compare_strings (c_s1, c_s2, locale, FUNC_NAME);
+
+ scm_remember_upto_here_2 (s1, s2);
+
+ return scm_from_bool (result < 0);
+}
+#undef FUNC_NAME
+
+/* XXX: Wrap GNU's `strcasecmp_l ()'? */
+
+
+SCM_DEFINE (scm_char_locale_lt, "char-locale<?", 2, 1, 0,
+ (SCM c1, SCM c2, SCM locale),
+ "Return true if character @var{c1} is lower than @var{c2} "
+ "according to @var{locale} or to the current locale.")
+#define FUNC_NAME s_scm_char_locale_lt
+{
+ char c_c1[2], c_c2[2];
+
+ SCM_VALIDATE_CHAR (1, c1);
+ SCM_VALIDATE_CHAR (2, c2);
+
+ c_c1[0] = (char)SCM_CHAR (c1); c_c1[1] = '\0';
+ c_c2[0] = (char)SCM_CHAR (c2); c_c2[1] = '\0';
+
+ return scm_from_bool (compare_strings (c_c1, c_c2, locale, FUNC_NAME) < 0);
+}
+#undef FUNC_NAME
+
+
+\f
+void
scm_init_i18n ()
{
scm_add_feature ("i18n");
+
+ scm_c_define ("LC_CTYPE_MASK", SCM_I_MAKINUM (LC_CTYPE_MASK));
+ scm_c_define ("LC_NUMERIC_MASK", SCM_I_MAKINUM (LC_NUMERIC_MASK));
+ scm_c_define ("LC_TIME_MASK", SCM_I_MAKINUM (LC_TIME_MASK));
+ scm_c_define ("LC_COLLATE_MASK", SCM_I_MAKINUM (LC_COLLATE_MASK));
+ scm_c_define ("LC_MONETARY_MASK", SCM_I_MAKINUM (LC_MONETARY_MASK));
+ scm_c_define ("LC_MESSAGES_MASK", SCM_I_MAKINUM (LC_MESSAGES_MASK));
+ scm_c_define ("LC_PAPER_MASK", SCM_I_MAKINUM (LC_PAPER_MASK));
+ scm_c_define ("LC_NAME_MASK", SCM_I_MAKINUM (LC_NAME_MASK));
+ scm_c_define ("LC_ADDRESS_MASK", SCM_I_MAKINUM (LC_ADDRESS_MASK));
+ scm_c_define ("LC_TELEPHONE_MASK", SCM_I_MAKINUM (LC_TELEPHONE_MASK));
+ scm_c_define ("LC_MEASUREMENT_MASK", SCM_I_MAKINUM (LC_MEASUREMENT_MASK));
+ scm_c_define ("LC_IDENTIFICATION_MASK", SCM_I_MAKINUM (LC_IDENTIFICATION_MASK));
+ scm_c_define ("LC_ALL_MASK", SCM_I_MAKINUM (LC_ALL_MASK));
+
#include "libguile/i18n.x"
}
--- orig/libguile/i18n.h
+++ mod/libguile/i18n.h
@@ -30,6 +30,10 @@
SCM_API int scm_i_to_lc_category (SCM category, int allow_lc_all);
+SCM_API SCM scm_make_locale (SCM category_mask, SCM locale_name, SCM base_locale);
+SCM_API SCM scm_string_locale_lt (SCM s1, SCM s2, SCM locale);
+SCM_API SCM scm_char_locale_lt (SCM c1, SCM c2, SCM locale);
+
SCM_API void scm_init_i18n (void);
#endif /* SCM_I18N_H */
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: Text collation 2006-09-19 9:23 Text collation Ludovic Courtès @ 2006-09-19 22:38 ` Kevin Ryde 2006-10-22 18:33 ` Ludovic Courtès 0 siblings, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-09-19 22:38 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > The cool thing is that it's a "clean" API in that the locale settings > can be passed explicitly as a third parameter. The (potentially) > controversial part is that this wraps a non-standard GNU extension. /usr/include/locale.h has Attention: all these functions are *not* standardized in any form. This is a proof-of-concept implementation. which is not confidence inspiring :(. > If all this sounds like a reasonable plan to you, then I can implement > locked locale sections (for non-GNU platforms), augment the docs, and > eventually merge it in both 1.8 and HEAD. I wonder if the unicode of r6rs might make the implementation difficult later. > PS: I would be happier if this was part of an `(ice-9 i18n)' module but > since it's already too late for `gettext', `bindtextdomain' and > friends to go there, maybe we should just keep using the root > module... If it doesn't drag in extra libraries then it doesn't hurt much. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-09-19 22:38 ` Kevin Ryde @ 2006-10-22 18:33 ` Ludovic Courtès 2006-10-23 2:01 ` Rob Browning ` (5 more replies) 0 siblings, 6 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-10-22 18:33 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 3698 bytes --] Hi, I have come up with an `(ice-9 i18n)' module that contains locale-dependent text collation functions and also character case mapping and functions to read numbers. There would be a lot more things to add, like `strfmon ()', but I think that's a good start. Here are the key points that may deserve further discussion: 1. Use of a glibc-specific reentrant API (the `_l' functions). As I mentioned in my previous post, the idea here is to provide the option to pass locale information as an additional argument, as in: (string-locale<? "hello" "world" my-locale) That last argument may be omitted, in which case the current process locale is used (and the "regular" C function is used behind the scenes). Note that in cases where this optional argument is not used, the implementation is exactly the same on both GNU and non-GNU systems. For non-GNU systems, I implemented this (dealing with the LOCALE argument) by serializing calls to `setlocale', and performing as many `setlocale' calls as needed to install the locale specified by this third argument (details in `i18n.c' below). This is not efficient nor very elegant, but at least, it provides users with the same semantics across all systems. There's one difference, though, between the behavior on GNU and non-GNU systems: on GNU, passing a wrong locale name to `make-locale' immediately yields an exception, while on non-GNU that exception will only be raised when the locale object is actually used. Kevin mentioned the argument in glibc's <locale.h> stating that the `locale_t' API was a "proof-of-concept". It seems, however, that it's built to stay [0]. 2. Kevin said: "I wonder if the unicode of r6rs might make the implementation difficult later." When we support Unicode, `i18n.c' "just" has to be changed to use the wide-character variants of the various functions (e.g., `wstrcoll' instead of `strcoll', etc.). So I don't think there's much to worry about here. 3. I've put those functions in `(ice-9 i18n)' but they are actually implemented in C so `i18n.scm' simply `dynamic-link's a new library, `libguile-i18n-v0', that is compiled from within the `libguile' directory. The rationale for doing it was the following: * Reduce startup time. The approach that consists in initializing _everything_ at startup is not scalable. * Optionally, reduce memory footprint when the module is not used, although that's arguably not a major concern. On IRC, Rob identified a number of issues with this approach: * It would be the first `ice-9' module that does a `dynamic-link', so we may want to think twice before doing it. * The C programmer willing to use those functions would have to link against `libguile-i18n' additionally. There's another (small) issue: * The online help is a bit confused because the doc of the i18n.c functions is include in libguile's `guile-procedure.txt'. Thus, `(help make-locale)' always works, even when `(ice-9 i18n)' is not loaded. Personally, I'm not worried about issues (1) and (2). As for item (3), I'd be tempted to leave the thing in a separate shared library. While I agree that this practically precludes use of those functions by C programmers (as is the case for those SRFIs that are implemented in C), I believe that this module is more targeted towards Scheme programmers and, consequently, I see more value in keeping the module's code in a separate shared lib than in providing access to the C functions. What do you think? Thanks, Ludovic. [0] http://sources.redhat.com/ml/libc-alpha/2006-09/msg00033.html [-- Attachment #2: The patch --] [-- Type: text/x-patch, Size: 67843 bytes --] --- orig/configure.in +++ mod/configure.in @@ -613,8 +613,9 @@ AC_CHECK_HEADERS([assert.h crt_externs.h # truncate - not in mingw # isblank - available as a GNU extension or in C99 # _NSGetEnviron - Darwin specific +# strcoll_l, newlocale - GNU extensions (glibc) # -AC_CHECK_FUNCS([DINFINITY DQNAN chsize clog10 ctermid fesetround ftime ftruncate fchown getcwd geteuid gettimeofday gmtime_r ioctl lstat mkdir mknod nice readdir_r readlink rename rmdir select setegid seteuid setlocale setpgid setsid sigaction siginterrupt stat64 strftime strptime symlink sync sysconf tcgetpgrp tcsetpgrp times uname waitpid strdup system usleep atexit on_exit chown link fcntl ttyname getpwent getgrent kill getppid getpgrp fork setitimer getitimer strchr strcmp index bcopy memcpy rindex truncate unsetenv isblank _NSGetEnviron]) +AC_CHECK_FUNCS([DINFINITY DQNAN chsize clog10 ctermid fesetround ftime ftruncate fchown getcwd geteuid gettimeofday gmtime_r ioctl lstat mkdir mknod nice readdir_r readlink rename rmdir select setegid seteuid setlocale setpgid setsid sigaction siginterrupt stat64 strftime strptime symlink sync sysconf tcgetpgrp tcsetpgrp times uname waitpid strdup system usleep atexit on_exit chown link fcntl ttyname getpwent getgrent kill getppid getpgrp fork setitimer getitimer strchr strcmp index bcopy memcpy rindex truncate unsetenv isblank _NSGetEnviron strcoll strcoll_l newlocale]) # Reasons for testing: # netdb.h - not in mingw --- orig/doc/ref/api-i18n.texi +++ mod/doc/ref/api-i18n.texi @@ -1,6 +1,6 @@ @c -*-texinfo-*- @c This is part of the GNU Guile Reference Manual. -@c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004 +@c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2006 @c Free Software Foundation, Inc. @c See the file guile.texi for copying conditions. @@ -8,6 +8,266 @@ @node Internationalization @section Support for Internationalization +@cindex internationalization +@cindex i18n + +Guile provides internationalization support for Scheme programs in two +ways. First, procedures to manipulate text and data in a way that +conforms to particular cultural conventions (i.e., in a +``locale-dependent'' way) are provided in the @code{(ice-9 i18n)}. +Second, Guile allows the use of GNU @code{gettext} to translate +program message strings. + +@menu +* The ice-9 i18n Module:: Honoring cultural conventions. +* Gettext Support:: Translating message strings. +@end menu + + +@node The ice-9 i18n Module +@subsection The @code{(ice-9 i18n)} Module + +In order to make use of the following functions, one must import the +@code{(ice-9 i18n)} module in the usual way: + +@example +(use-modules (ice-9 i18n)) +@end example + +@cindex cultural conventions + +The @code{(ice-9 i18n)} module provides procedures to manipulate text +and other data in a way that conforms to the cultural conventions +chosen by the user. Each region of the world or language has its own +customs to, for instance, represent real numbers, classify characters, +collate text, etc. All these aspects comprise the so-called +``cultural conventions'' of that region or language. + +@cindex locale +@cindex locale category + +Computer systems typically refer to a set of cultural conventions as a +@dfn{locale}. For each particular aspect that comprise those cultural +conventions, a @dfn{locale category} is defined. For instance, the +way characters are classified is defined by the @code{LC_CTYPE} +category, while the language in which program messages are issued to +the user is defined by the @code{LC_MESSAGES} category +(@pxref{Locales, General Locale Information} for details). + +@cindex locale object + +The procedures provided by this module allow the development of +programs that adapt automatically to any locale setting. As we will +see later, many of the locale-dependent procedures provided by this +module can optionally take a @dfn{locale object} argument. This +additional argument defines the locale settings that must be followed +by the invoked procedure. When it is omitted, then the current locale +settings of the process are followed (@pxref{Locales, +@code{setlocale}}). + +The following procedures allow the manipulation of such locale +objects. + +@deffn {Scheme Procedure} make-locale category_mask locale_name [base_locale] +Return a reference to a data structure representing a set of locale +datasets. Unlike for the @var{category} parameter for +@code{setlocale}, the @var{category_mask} parameter here uses a single +bit for each category, made by OR'ing together @code{LC_*_MASK} bits. +The optional @var{base_locale} argument can be used to specify a +locale object whose settings are to be used as a basis for the locale +object being returned. + +The available locale category masks are the following: + +@defvar LC_COLLATE_MASK +Represents the collation locale category. +@end defvar +@defvar LC_CTYPE_MASK +Represents the character classification locale category. +@end defvar +@defvar LC_MESSAGES_MASK +Represents the messages locale category. +@end defvar +@defvar LC_MONETARY_MASK +Represents the monetary locale category. +@end defvar +@defvar LC_NUMERIC_MASK +Represents the way numbers are displayed. +@end defvar +@defvar LC_TIME_MASK +Represents the way date and time are displayed +@end defvar + +The following category masks are also available but will not have any +effect on systems that do not support them: + +@defvar LC_PAPER_MASK +@defvarx LC_NAME_MASK +@defvarx LC_ADDRESS_MASK +@defvarx LC_TELEPHONE_MASK +@defvarx LC_MEASUREMENT_MASK +@defvarx LC_IDENTIFICATION_MASK +@end defvar + +Finally, there is also: + +@defvar LC_ALL_MASK +This represents all the locale categories supported by the system. +@end defvar + +The @code{LC_*_MASK} variables are bound to integers which may be OR'd +together using @code{logior} (@pxref{Primitive Numerics, +@code{logior}}). For instance, the following invocation creates a +locale object that combines the use of Esperanto for messages and +character classification with the default settings for the other +categories (i.e., the settings of the default @code{C} locale which +usually represents conventions in use in the USA): + +@example +(make-locale (logior LC_MESSAGE_MASK LC_CTYPE_MASK) "eo_EO") +@end example + +The following example combines the use of Swedish conventions with +monetary conventions from Croatia: + +@example +(make-locale LC_MONETARY_MASK "hr_HR" + (make-locale LC_ALL_MASK "sv_SE")) +@end example + +A @code{system-error} exception (@pxref{Handling Errors}) is raised by +@code{make-locale} when @var{locale_name} does not match any of the +locales compiled on the system. + +@end deffn + +@deffn {Scheme Procedure} locale? obj +Return true if @var{obj} is a locale object. +@end deffn + +The following procedures provide support for text collation. + +@deffn {Scheme Procedure} string-locale<? s1 s2 [locale] +Compare strings @var{s1} and @var{s2} in a locale-dependent way. If +@var{locale} is provided, it should be locale object (as returned by +@code{make-locale}) and will be used to perform the comparison; +otherwise, the current system locale is used. +@end deffn + +@deffn {Scheme Procedure} string-locale>? s1 s2 [locale] +Compare strings @var{s1} and @var{s2} in a locale-dependent way. If +@var{locale} is provided, it should be locale object (as returned by +@code{make-locale}) and will be used to perform the comparison; +otherwise, the current system locale is used. +@end deffn + +@deffn {Scheme Procedure} string-locale-ci<? s1 s2 [locale] +Compare strings @var{s1} and @var{s2} in a case-insensitive, and +locale-dependent way. If @var{locale} is provided, it should be +locale object (as returned by @code{make-locale}) and will be used to +perform the comparison; otherwise, the current system locale is used. +@end deffn + +@deffn {Scheme Procedure} string-locale-ci>? s1 s2 [locale] +Compare strings @var{s1} and @var{s2} in a case-insensitive, and +locale-dependent way. If @var{locale} is provided, it should be +locale object (as returned by @code{make-locale}) and will be used to +perform the comparison; otherwise, the current system locale is used. +@end deffn + +@deffn {Scheme Procedure} string-locale-ci=? s1 s2 [locale] +Compare strings @var{s1} and @var{s2} in a case-insensitive, and +locale-dependent way. If @var{locale} is provided, it should be +locale object (as returned by @code{make-locale}) and will be used to +perform the comparison; otherwise, the current system locale is used. +@end deffn + +@deffn {Scheme Procedure} char-locale<? c1 c2 [locale] +Return true if character @var{c1} is lower than @var{c2} according to +@var{locale} or to the current locale. +@end deffn + +@deffn {Scheme Procedure} char-locale>? c1 c2 [locale] +Return true if character @var{c1} is greater than @var{c2} according +to @var{locale} or to the current locale. +@end deffn + +@deffn {Scheme Procedure} char-locale-ci<? c1 c2 [locale] +Return true if character @var{c1} is lower than @var{c2}, in a case +insensitive way according to @var{locale} or to the current locale. +@end deffn + +@deffn {Scheme Procedure} char-locale-ci>? c1 c2 [locale] +Return true if character @var{c1} is greater than @var{c2}, in a case +insensitive way according to @var{locale} or to the current locale. +@end deffn + +@deffn {Scheme Procedure} char-locale-ci=? c1 c2 [locale] +Return true if character @var{c1} is equal to @var{c2}, in a case +insensitive way according to @var{locale} or to the current locale. +@end deffn + +The procedures below provide support for ``character case mapping'', +i.e., to convert characters or strings to their upper-case or +lower-case equivalent. Note that SRFI-13 provides procedures that +look similar (@pxref{Alphabetic Case Mapping}). However, the SRFI-13 +procedures are locale-independent. Therefore, they do not take into +account specificities of the customs in use in a particular language +or region of the world. For instance, while most languages using the +Latin alphabet map lower-case letter ``i'' to upper-case letter ``I'', +Turkish maps lower-case ``i'' to ``Latin capital letter I with dot +above''. The following procedures allow to provide idiomatic +character mapping. + +@deffn {Scheme Procedure} char-locale-downcase chr [locale] +Return the lowercase character that corresponds to @var{chr} according +to either @var{locale} or the current locale. +@end deffn + +@deffn {Scheme Procedure} char-locale-upcase chr [locale] +Return the uppercase character that corresponds to @var{chr} according +to either @var{locale} or the current locale. +@end deffn + +@deffn {Scheme Procedure} string-locale-upcase str [locale] +Return a new string that is the uppercase version of @var{str} +according to either @var{locale} or the current locale. +@end deffn + +@deffn {Scheme Procedure} string-locale-downcase str [locale] +Return a new string that is the down-case version of @var{str} +according to either @var{locale} or the current locale. +@end deffn + +Finally, the following procedures allow programs to read numbers +written according to a particular locale. As an example, in English, +``ten thousand and a half'' is usually written @code{10,000.5} while +in French it is written @code{10000,5}. These procedures allow to +account for this differences. + +@deffn {Scheme Procedure} locale-string->integer str [base [locale]] +Convert string @var{str} into an integer according to either +@var{locale} (a locale object as returned by @code{make-locale}) or +the current process locale. If @var{base} is specified, then it +determines the base of the integer being read (e.g., @code{16} for an +hexadecimal number, @code{10} for a decimal number); by default, +decimal numbers are read. Return two values: an integer (on success) +or @code{#f}, and the number of characters read from @var{str} +(@code{0} on failure). +@end deffn + +@deffn {Scheme Procedure} locale-string->inexact str [locale] +Convert string @var{str} into an inexact number according to either +@var{locale} (a locale object as returned by @code{make-locale}) or +the current process locale. Return two values: an inexact number (on +success) or @code{#f}, and the number of characters read from +@var{str} (@code{0} on failure). +@end deffn + + +@node Gettext Support +@subsection Gettext Support + Guile provides an interface to GNU @code{gettext} for translating message strings (@pxref{Introduction,,, gettext, GNU @code{gettext} utilities}). @@ -155,4 +415,5 @@ future. @c Local Variables: @c TeX-master: "guile.texi" +@c ispell-local-dictionary: "american" @c End: --- orig/doc/ref/posix.texi +++ mod/doc/ref/posix.texi @@ -1,6 +1,6 @@ @c -*-texinfo-*- @c This is part of the GNU Guile Reference Manual. -@c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004 +@c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2006 @c Free Software Foundation, Inc. @c See the file guile.texi for copying conditions. @@ -3159,6 +3159,10 @@ categories based on standard environment For full details on categories and locale names @pxref{Locales,, Locales and Internationalization, libc, The GNU C Library Reference Manual}. + +Note that @code{setlocale} affects locale settings for the whole +process. For a safer, thread-safe and reentrant alternative, +@xref{The ice-9 i18n Module, Locale Objects and @code{make-locale}}. @end deffn @node Encryption --- orig/libguile/Makefile.am +++ mod/libguile/Makefile.am @@ -31,7 +31,7 @@ INCLUDES = -I.. -I$(top_srcdir) ETAGS_ARGS = --regex='/SCM_\(GLOBAL_\)?\(G?PROC\|G?PROC1\|SYMBOL\|VCELL\|CONST_LONG\).*\"\([^\"]\)*\"/\3/' \ --regex='/[ \t]*SCM_[G]?DEFINE1?[ \t]*(\([^,]*\),[^,]*/\1/' -lib_LTLIBRARIES = libguile.la +lib_LTLIBRARIES = libguile.la libguile-i18n-v0.la bin_PROGRAMS = guile noinst_PROGRAMS = guile_filter_doc_snarfage gen-scmconfig @@ -97,9 +97,10 @@ libguile_la_SOURCES = alist.c arbiters.c deprecated.c discouraged.c dynwind.c environments.c eq.c error.c \ eval.c evalext.c extensions.c feature.c fluids.c fports.c \ futures.c gc.c gc-mark.c gc-segment.c gc-malloc.c gc-card.c \ - gc-freelist.c gc_os_dep.c gdbint.c gh_data.c gh_eval.c gh_funcs.c \ + gc-freelist.c gc_os_dep.c gdbint.c gettext.c \ + gh_data.c gh_eval.c gh_funcs.c \ gh_init.c gh_io.c gh_list.c gh_predicates.c goops.c gsubr.c \ - guardians.c hash.c hashtab.c hooks.c i18n.c init.c inline.c \ + guardians.c hash.c hashtab.c hooks.c init.c inline.c \ ioext.c keywords.c lang.c list.c load.c macros.c mallocs.c \ modules.c numbers.c objects.c objprop.c options.c pairs.c ports.c \ print.c procprop.c procs.c properties.c random.c rdelim.c read.c \ @@ -109,11 +110,16 @@ libguile_la_SOURCES = alist.c arbiters.c throw.c values.c variable.c vectors.c version.c vports.c weaks.c \ ramap.c unif.c +libguile_i18n_v0_la_SOURCES = i18n.c +libguile_i18n_v0_la_CFLAGS = $(libguile_la_CFLAGS) +libguile_i18n_v0_la_LDFLAGS = -module -L$(builddir) -lguile + DOT_X_FILES = alist.x arbiters.x async.x backtrace.x boolean.x chars.x \ continuations.x debug.x deprecation.x deprecated.x discouraged.x \ dynl.x dynwind.x environments.x eq.x error.x eval.x evalext.x \ extensions.x feature.x fluids.x fports.x futures.x gc.x gc-mark.x \ - gc-segment.x gc-malloc.x gc-card.x goops.x gsubr.x guardians.x \ + gc-segment.x gc-malloc.x gc-card.x gettext.x goops.x \ + gsubr.x guardians.x \ hash.x hashtab.x hooks.x i18n.x init.x ioext.x keywords.x lang.x \ list.x load.x macros.x mallocs.x modules.x numbers.x objects.x \ objprop.x options.x pairs.x ports.x print.x procprop.x procs.x \ @@ -131,7 +137,8 @@ DOT_DOC_FILES = alist.doc arbiters.doc a environments.doc eq.doc error.doc eval.doc evalext.doc \ extensions.doc feature.doc fluids.doc fports.doc futures.doc \ gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc \ - gc-malloc.doc gc-card.doc guardians.doc hash.doc hashtab.doc \ + gc-malloc.doc gc-card.doc gettext.doc \ + guardians.doc hash.doc hashtab.doc \ hooks.doc i18n.doc init.doc ioext.doc keywords.doc lang.doc \ list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc \ objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc \ @@ -153,8 +160,9 @@ EXTRA_libguile_la_SOURCES = _scm.h \ inet_aton.c memmove.c putenv.c strerror.c \ dynl.c regex-posix.c \ filesys.c posix.c net_db.c socket.c \ - debug-malloc.c mkstemp.c \ - win32-uname.c win32-dirent.c win32-socket.c + debug-malloc.c mkstemp.c \ + win32-uname.c win32-dirent.c win32-socket.c \ + locale-categories.h ## delete guile-snarf.awk from the installation bindir, in case it's ## lingering there due to an earlier guile version not having been @@ -187,7 +195,8 @@ modinclude_HEADERS = __scm.h alist.h arb deprecation.h deprecated.h discouraged.h dynl.h dynwind.h \ environments.h eq.h error.h eval.h evalext.h extensions.h \ feature.h filesys.h fluids.h fports.h futures.h gc.h \ - gdb_interface.h gdbint.h goops.h gsubr.h guardians.h hash.h \ + gdb_interface.h gdbint.h gettext.h goops.h \ + gsubr.h guardians.h hash.h \ hashtab.h hooks.h i18n.h init.h inline.h ioext.h iselect.h \ keywords.h lang.h list.h load.h macros.h mallocs.h modules.h \ net_db.h numbers.h objects.h objprop.h options.h pairs.h ports.h \ @@ -212,7 +221,7 @@ EXTRA_DIST = ChangeLog-gh ChangeLog-scm cpp_errno.c cpp_err_symbols.in cpp_err_symbols.c \ cpp_sig_symbols.c cpp_sig_symbols.in cpp_cnvt.awk \ c-tokenize.lex version.h.in \ - scmconfig.h.top gettext.h + scmconfig.h.top libgettext.h # $(DOT_DOC_FILES) $(EXTRA_DOT_DOC_FILES) \ # guile-procedures.txt guile.texi --- orig/libguile/i18n.c +++ mod/libguile/gettext.c @@ -22,11 +22,11 @@ #include "libguile/_scm.h" #include "libguile/feature.h" -#include "libguile/i18n.h" #include "libguile/strings.h" #include "libguile/dynwind.h" -#include "gettext.h" +#include "libguile/gettext.h" +#include "libgettext.h" #include <locale.h> @@ -312,11 +312,15 @@ SCM_DEFINE (scm_bind_textdomain_codeset, } #undef FUNC_NAME -void -scm_init_i18n () +void +scm_init_gettext () { + /* When gettext support was first added (in 1.8.0), it provided feature + `i18n'. We keep this as is although the name is a bit misleading + now. */ scm_add_feature ("i18n"); -#include "libguile/i18n.x" + +#include "libguile/gettext.x" } --- orig/libguile/i18n.h +++ mod/libguile/gettext.h @@ -1,7 +1,7 @@ /* classes: h_files */ -#ifndef SCM_I18N_H -#define SCM_I18N_H +#ifndef SCM_GETTEXT_H +#define SCM_GETTEXT_H /* Copyright (C) 2004, 2006 Free Software Foundation, Inc. * @@ -30,9 +30,9 @@ SCM_API SCM scm_bind_textdomain_codeset SCM_API int scm_i_to_lc_category (SCM category, int allow_lc_all); -SCM_API void scm_init_i18n (void); +SCM_API void scm_init_gettext (void); -#endif /* SCM_I18N_H */ +#endif /* SCM_GETTEXT_H */ /* Local Variables: --- orig/libguile/init.c +++ mod/libguile/init.c @@ -63,7 +63,7 @@ #include "libguile/hash.h" #include "libguile/hashtab.h" #include "libguile/hooks.h" -#include "libguile/i18n.h" +#include "libguile/gettext.h" #include "libguile/iselect.h" #include "libguile/ioext.h" #include "libguile/keywords.h" @@ -473,7 +473,7 @@ scm_i_init_guile (SCM_STACKITEM *base) scm_init_properties (); scm_init_hooks (); /* Requires smob_prehistory */ scm_init_gc (); /* Requires hooks, async */ - scm_init_i18n (); + scm_init_gettext (); scm_init_ioext (); scm_init_keywords (); scm_init_list (); --- orig/libguile/posix.c +++ mod/libguile/posix.c @@ -40,7 +40,7 @@ #include "libguile/validate.h" #include "libguile/posix.h" -#include "libguile/i18n.h" +#include "libguile/gettext.h" #include "libguile/threads.h" \f @@ -115,6 +115,10 @@ extern char ** environ; #include <locale.h> #endif +#if (defined HAVE_NEWLOCALE) && (defined HAVE_STRCOLL_L) +# define USE_GNU_LOCALE_API +#endif + #if HAVE_CRYPT_H # include <crypt.h> #endif @@ -1380,7 +1384,15 @@ SCM_DEFINE (scm_putenv, "putenv", 1, 0, } #undef FUNC_NAME +#ifndef USE_GNU_LOCALE_API +/* This mutex is used to serialize invocations of `setlocale ()' on non-GNU + systems (i.e., systems where a reentrant locale API is not available). + See `i18n.c' for details. */ +scm_i_pthread_mutex_t scm_i_locale_mutex; +#endif + #ifdef HAVE_SETLOCALE + SCM_DEFINE (scm_setlocale, "setlocale", 1, 1, 0, (SCM category, SCM locale), "If @var{locale} is omitted, return the current value of the\n" @@ -1409,7 +1421,14 @@ SCM_DEFINE (scm_setlocale, "setlocale", scm_dynwind_free (clocale); } +#ifndef USE_GNU_LOCALE_API + scm_i_pthread_mutex_lock (&scm_i_locale_mutex); +#endif rv = setlocale (scm_i_to_lc_category (category, 1), clocale); +#ifndef USE_GNU_LOCALE_API + scm_i_pthread_mutex_unlock (&scm_i_locale_mutex); +#endif + if (rv == NULL) { /* POSIX and C99 don't say anything about setlocale setting errno, so @@ -1943,9 +1962,13 @@ SCM_DEFINE (scm_gethostname, "gethostnam #endif /* HAVE_GETHOSTNAME */ -void +void scm_init_posix () { +#ifndef USE_GNU_LOCALE_API + scm_i_pthread_mutex_init (&scm_i_locale_mutex, NULL); +#endif + scm_add_feature ("posix"); #ifdef HAVE_GETEUID scm_add_feature ("EIDs"); --- orig/libguile/posix.h +++ mod/libguile/posix.h @@ -23,8 +23,7 @@ \f #include "libguile/__scm.h" - -\f +#include "libguile/threads.h" \f @@ -87,6 +86,8 @@ SCM_API SCM scm_sethostname (SCM name); SCM_API SCM scm_gethostname (void); SCM_API void scm_init_posix (void); +SCM_API scm_i_pthread_mutex_t scm_i_locale_mutex; + #endif /* SCM_POSIX_H */ /* --- orig/test-suite/Makefile.am +++ mod/test-suite/Makefile.am @@ -43,6 +43,7 @@ SCM_TESTS = tests/alist.test \ tests/guardians.test \ tests/hash.test \ tests/hooks.test \ + tests/i18n.test \ tests/import.test \ tests/interp.test \ tests/list.test \ * added files --- /dev/null +++ mod/ice-9/.arch-ids/i18n.scm.id @@ -0,0 +1 @@ +Ludovic Courtes <ludovic.courtes@laas.fr> Sat Oct 21 16:12:32 2006 29433.0 --- /dev/null +++ mod/ice-9/i18n.scm @@ -0,0 +1,68 @@ +;;;; i18n.scm --- internationalization support + +;;;; Copyright (C) 2006 Free Software Foundation, Inc. +;;;; +;;;; This library is free software; you can redistribute it and/or +;;;; modify it under the terms of the GNU Lesser General Public +;;;; License as published by the Free Software Foundation; either +;;;; version 2.1 of the License, or (at your option) any later version. +;;;; +;;;; This library is distributed in the hope that it will be useful, +;;;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;;;; Lesser General Public License for more details. +;;;; +;;;; You should have received a copy of the GNU Lesser General Public +;;;; License along with this library; if not, write to the Free Software +;;;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + +;;; Author: Ludovic Courtès <ludovic.courtes@laas.fr> + +;;; Commentary: +;;; +;;; This module provides a number of routines that support +;;; internationalization (e.g., locale-dependent text collation, character +;;; mapping, etc.). It also defines `locale' objects, representing locale +;;; settings, that may be passed around to most of these procedures. +;;; + +;;; Code: + +(define-module (ice-9 i18n) + :export (;; `locale' type + make-locale locale? + + ;; locale category masks (standard) + LC_ALL_MASK + LC_COLLATE_MASK LC_CTYPE_MASK LC_MESSAGES_MASK + LC_MONETARY_MASK LC_NUMERIC_MASK LC_TIME_MASK + + ;; locale category masks (non-standard) + LC_PAPER_MASK LC_NAME_MASK LC_ADDRESS_MASK + LC_TELEPHONE_MASK LC_MEASUREMENT_MASK + LC_IDENTIFICATION_MASK + + ;; text collation + string-locale<? string-locale>? + string-locale-ci<? string-locale-ci>? string-locale-ci=? + + char-locale<? char-locale>? + char-locale-ci<? char-locale-ci>? char-locale-ci=? + + ;; character mapping + char-locale-downcase char-locale-upcase + string-locale-downcase string-locale-upcase + + ;; reading numbers + locale-string->integer locale-string->inexact)) + + +(dynamic-call "scm_init_i18n" + (dynamic-link "libguile-i18n-v0")) + + +;;; Local Variables: +;;; coding: latin-1 +;;; End: + +;;; i18n.scm ends here --- /dev/null +++ mod/libguile/.arch-ids/i18n.c.id @@ -0,0 +1 @@ +Ludovic Courtes <ludovic.courtes@laas.fr> Sat Oct 21 17:24:34 2006 11178.0 --- /dev/null +++ mod/libguile/.arch-ids/i18n.h.id @@ -0,0 +1 @@ +Ludovic Courtes <ludovic.courtes@laas.fr> Sat Oct 21 17:24:44 2006 11192.0 --- /dev/null +++ mod/libguile/.arch-ids/locale-categories.h.id @@ -0,0 +1 @@ +Ludovic Courtes <ludovic.courtes@laas.fr> Sat Oct 14 17:20:45 2006 6695.0 --- /dev/null +++ mod/libguile/i18n.c @@ -0,0 +1,1161 @@ +/* Copyright (C) 2006 Free Software Foundation, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#define _GNU_SOURCE /* Ask for glibc's `newlocale' API */ + +#if HAVE_CONFIG_H +# include <config.h> +#endif + +#if HAVE_ALLOCA_H +# include <alloca.h> +#elif defined __GNUC__ +# define alloca __builtin_alloca +#elif defined _AIX +# define alloca __alloca +#elif defined _MSC_VER +# include <malloc.h> +# define alloca _alloca +#else +# include <stddef.h> +# ifdef __cplusplus +extern "C" +# endif +void *alloca (size_t); +#endif + +#include "libguile/_scm.h" +#include "libguile/feature.h" +#include "libguile/i18n.h" +#include "libguile/strings.h" +#include "libguile/chars.h" +#include "libguile/dynwind.h" +#include "libguile/validate.h" +#include "libguile/values.h" + +#include <locale.h> +#include <string.h> /* `strcoll ()' */ +#include <ctype.h> /* `toupper ()' et al. */ +#include <errno.h> + +#if (defined HAVE_NEWLOCALE) && (defined HAVE_STRCOLL_L) +# define USE_GNU_LOCALE_API +#endif + +#ifndef USE_GNU_LOCALE_API +# include "libguile/posix.h" /* for `scm_i_locale_mutex' */ +#endif + +#ifndef HAVE_SETLOCALE +static inline char * +setlocale (int category, const char *name) +{ + errno = ENOSYS; + return NULL; +} +#endif + + +\f +/* Locale objects, string and character collation, and other locale-dependent + string operations. + + A large part of the code here deals with emulating glibc's reentrant + locale API on non-GNU systems. The emulation is a bit "brute-force": + Whenever a `-locale<?' procedure is passed a locale object, then: + + 1. The `scm_t_locale_mutex' is locked. + 2. A series of `setlocale ()' call is performed to store the current + locale for each category in an `scm_t_locale_settings' object. + 3. A series of `setlocale ()' call is made to install each of the locale + categories of each of the base locales of each locale object, + recursively, starting from the last locale object of the chain. + 4. The settings captured in step (2) are restored. + 5. The `scm_t_locale_mutex' is released. + + Hopefully, some smart standard will make that hack useless someday... + A similar API can be found in MzScheme starting from version 200: + http://download.plt-scheme.org/chronology/mzmr200alpha14.html . + + Note: We don't wrap glibc's `uselocale ()' call because it sets the locale + of the current _thread_ (unlike `setlocale ()') and doing so would require + maintaining per-thread locale information on non-GNU systems and always + re-installing this locale upon locale-dependent calls. */ + + +#ifndef USE_GNU_LOCALE_API + +/* Provide the locale category masks as found in glibc (copied from + <locale.h> as found in glibc 2.3.6). This must be kept in sync with + `locale-categories.h'. */ + +# define LC_CTYPE_MASK (1 << LC_CTYPE) +# define LC_COLLATE_MASK (1 << LC_COLLATE) +# define LC_MESSAGES_MASK (1 << LC_MESSAGES) +# define LC_MONETARY_MASK (1 << LC_MONETARY) +# define LC_NUMERIC_MASK (1 << LC_NUMERIC) +# define LC_TIME_MASK (1 << LC_TIME) + +# ifdef LC_PAPER +# define LC_PAPER_MASK (1 << LC_PAPER) +# else +# define LC_PAPER_MASK 0 +# endif +# ifdef LC_NAME +# define LC_NAME_MASK (1 << LC_NAME) +# else +# define LC_NAME_MASK 0 +# endif +# ifdef LC_ADDRESS +# define LC_ADDRESS_MASK (1 << LC_ADDRESS) +# else +# define LC_ADDRESS_MASK 0 +# endif +# ifdef LC_TELEPHONE +# define LC_TELEPHONE_MASK (1 << LC_TELEPHONE) +# else +# define LC_TELEPHONE_MASK 0 +# endif +# ifdef LC_MEASUREMENT +# define LC_MEASUREMENT_MASK (1 << LC_MEASUREMENT) +# else +# define LC_MEASUREMENT_MASK 0 +# endif +# ifdef LC_IDENTIFICATION +# define LC_IDENTIFICATION_MASK (1 << LC_IDENTIFICATION) +# else +# define LC_IDENTIFICATION_MASK 0 +# endif + +# define LC_ALL_MASK (LC_CTYPE_MASK \ + | LC_NUMERIC_MASK \ + | LC_TIME_MASK \ + | LC_COLLATE_MASK \ + | LC_MONETARY_MASK \ + | LC_MESSAGES_MASK \ + | LC_PAPER_MASK \ + | LC_NAME_MASK \ + | LC_ADDRESS_MASK \ + | LC_TELEPHONE_MASK \ + | LC_MEASUREMENT_MASK \ + | LC_IDENTIFICATION_MASK \ + ) + +/* Locale objects as returned by `make-locale' on non-GNU systems. */ +typedef struct scm_locale +{ + SCM base_locale; /* a `locale' object */ + char *locale_name; + int category_mask; +} *scm_t_locale; + +#else + +/* Alias for glibc's locale type. */ +typedef locale_t scm_t_locale; + +#endif + +/* Validate parameter ARG as a locale object and set C_LOCALE to the + corresponding C locale object. */ +#define SCM_VALIDATE_LOCALE_COPY(_pos, _arg, _c_locale) \ + do \ + { \ + SCM_VALIDATE_SMOB ((_pos), (_arg), locale_smob_type); \ + (_c_locale) = (scm_t_locale)SCM_SMOB_DATA (_arg); \ + } \ + while (0) + +/* Validate optional parameter ARG as either undefined or bound to a locale + object. Set C_LOCALE to the corresponding C locale object or NULL. */ +#define SCM_VALIDATE_OPTIONAL_LOCALE_COPY(_pos, _arg, _c_locale) \ + do \ + { \ + if ((_arg) != SCM_UNDEFINED) \ + SCM_VALIDATE_LOCALE_COPY (_pos, _arg, _c_locale); \ + else \ + (_c_locale) = NULL; \ + } \ + while (0) + + +SCM_SMOB (scm_tc16_locale_smob_type, "locale", 0); + +SCM_SMOB_FREE (scm_tc16_locale_smob_type, smob_locale_free, locale) +{ + scm_t_locale c_locale; + + c_locale = (scm_t_locale)SCM_SMOB_DATA (locale); + +#ifdef USE_GNU_LOCALE_API + freelocale ((locale_t)c_locale); +#else + c_locale->base_locale = SCM_UNDEFINED; + free (c_locale->locale_name); + + scm_gc_free (c_locale, sizeof (* c_locale), "locale"); +#endif + + return 0; +} + +#ifndef USE_GNU_LOCALE_API +static SCM +smob_locale_mark (SCM locale) +{ + scm_t_locale c_locale; + + c_locale = (scm_t_locale)SCM_SMOB_DATA (locale); + return (c_locale->base_locale); +} +#endif + + +SCM_DEFINE (scm_make_locale, "make-locale", 2, 1, 0, + (SCM category_mask, SCM locale_name, SCM base_locale), + "Return a reference to a data structure representing a set of " + "locale datasets. Unlike for the @var{category} parameter for " + "@code{setlocale}, the @var{category_mask} parameter here uses " + "a single bit for each category, made by OR'ing together " + "@code{LC_*_MASK} bits.") +#define FUNC_NAME s_scm_make_locale +{ + SCM locale = SCM_BOOL_F; + int c_category_mask; + char *c_locale_name; + scm_t_locale c_base_locale, c_locale; + + SCM_VALIDATE_INT_COPY (1, category_mask, c_category_mask); + SCM_VALIDATE_STRING (2, locale_name); + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (3, base_locale, c_base_locale); + + c_locale_name = scm_to_locale_string (locale_name); + +#ifdef USE_GNU_LOCALE_API + + c_locale = newlocale (c_category_mask, c_locale_name, c_base_locale); + + if (!c_locale) + locale = SCM_BOOL_F; + else + SCM_NEWSMOB (locale, scm_tc16_locale_smob_type, c_locale); + + free (c_locale_name); + +#else + + c_locale = scm_gc_malloc (sizeof (* c_locale), "locale"); + c_locale->base_locale = base_locale; + + c_locale->category_mask = c_category_mask; + c_locale->locale_name = c_locale_name; + + SCM_NEWSMOB (locale, scm_tc16_locale_smob_type, c_locale); + +#endif + + return locale; +} +#undef FUNC_NAME + +SCM_DEFINE (scm_locale_p, "locale?", 1, 0, 0, + (SCM obj), + "Return true if @var{obj} is a locale object.") +#define FUNC_NAME s_scm_locale_p +{ + if (SCM_SMOB_PREDICATE (scm_tc16_locale_smob_type, obj)) + return SCM_BOOL_T; + + return SCM_BOOL_F; +} +#undef FUNC_NAME + + +\f +#ifndef USE_GNU_LOCALE_API /* Emulate GNU's reentrant locale API. */ + + +/* Maximum number of chained locales (via `base_locale'). */ +#define LOCALE_STACK_SIZE_MAX 256 + +typedef struct +{ +#define SCM_DEFINE_LOCALE_CATEGORY(_name) char * _name; +#include "locale-categories.h" +#undef SCM_DEFINE_LOCALE_CATEGORY +} scm_t_locale_settings; + +/* Fill out SETTINGS according to the current locale settings. On success + zero is returned and SETTINGS is properly initialized. */ +static int +get_current_locale_settings (scm_t_locale_settings *settings) +{ + const char *locale_name; + +#define SCM_DEFINE_LOCALE_CATEGORY(_name) \ + { \ + SCM_SYSCALL (locale_name = setlocale (LC_ ## _name, NULL)); \ + if (!locale_name) \ + goto handle_error; \ + \ + settings-> _name = strdup (locale_name); \ + if (settings-> _name == NULL) \ + goto handle_oom; \ + } + +#include "locale-categories.h" +#undef SCM_DEFINE_LOCALE_CATEGORY + + return 0; + + handle_error: + return errno; + + handle_oom: + return ENOMEM; +} + +/* Restore locale settings SETTINGS. On success, return zero. */ +static int +restore_locale_settings (const scm_t_locale_settings *settings) +{ + const char *result; + +#define SCM_DEFINE_LOCALE_CATEGORY(_name) \ + SCM_SYSCALL (result = setlocale (LC_ ## _name, settings-> _name)); \ + if (result == NULL) \ + goto handle_error; + +#include "locale-categories.h" +#undef SCM_DEFINE_LOCALE_CATEGORY + + return 0; + + handle_error: + return errno; +} + +/* Free memory associated with SETTINGS. */ +static void +free_locale_settings (scm_t_locale_settings *settings) +{ +#define SCM_DEFINE_LOCALE_CATEGORY(_name) \ + free (settings-> _name); \ + settings->_name = NULL; +#include "locale-categories.h" +#undef SCM_DEFINE_LOCALE_CATEGORY +} + +/* Install the locale named LOCALE_NAME for all the categories listed in + CATEGORY_MASK. */ +static int +install_locale_categories (const char *locale_name, int category_mask) +{ + const char *result; + + if (category_mask == LC_ALL_MASK) + { + SCM_SYSCALL (result = setlocale (LC_ALL, locale_name)); + if (result == NULL) + goto handle_error; + } + else + { +#define SCM_DEFINE_LOCALE_CATEGORY(_name) \ + if (category_mask & LC_ ## _name ## _MASK) \ + { \ + SCM_SYSCALL (result = setlocale (LC_ ## _name, locale_name)); \ + if (result == NULL) \ + goto handle_error; \ + } +#include "locale-categories.h" +#undef SCM_DEFINE_LOCALE_CATEGORY + } + + return 0; + + handle_error: + return errno; +} + +/* Install LOCALE, recursively installing its base locales first. On + success, zero is returned. */ +static int +install_locale (scm_t_locale locale) +{ + scm_t_locale stack[LOCALE_STACK_SIZE_MAX]; + size_t stack_size = 0; + int stack_offset = 0; + const char *result = NULL; + + /* Build up a locale stack by traversing the `base_locale' link. */ + do + { + if (stack_size >= LOCALE_STACK_SIZE_MAX) + /* We cannot use `scm_error ()' here because otherwise the locale + mutex may remain locked. */ + return EINVAL; + + stack[stack_size++] = locale; + + if (locale->base_locale != SCM_UNDEFINED) + locale = (scm_t_locale)SCM_SMOB_DATA (locale->base_locale); + else + locale = NULL; + } + while (locale != NULL); + + /* Install the C locale to start from a pristine state. */ + SCM_SYSCALL (result = setlocale (LC_ALL, "C")); + if (result == NULL) + goto handle_error; + + /* Install the locales in reverse order. */ + for (stack_offset = stack_size - 1; + stack_offset >= 0; + stack_offset--) + { + int err; + scm_t_locale locale; + + locale = stack[stack_offset]; + err = install_locale_categories (locale->locale_name, + locale->category_mask); + if (err) + goto handle_error; + } + + return 0; + + handle_error: + return errno; +} + +/* Leave the locked locale section. */ +static inline void +leave_locale_section (const scm_t_locale_settings *settings) +{ + /* Restore the previous locale settings. */ + (void)restore_locale_settings (settings); + + scm_i_pthread_mutex_unlock (&scm_i_locale_mutex); +} + +/* Enter a locked locale section. */ +static inline int +enter_locale_section (scm_t_locale locale, + scm_t_locale_settings *prev_locale) +{ + int err; + + scm_i_pthread_mutex_lock (&scm_i_locale_mutex); + + err = get_current_locale_settings (prev_locale); + if (err) + { + scm_i_pthread_mutex_unlock (&scm_i_locale_mutex); + return err; + } + + err = install_locale (locale); + if (err) + { + leave_locale_section (prev_locale); + free_locale_settings (prev_locale); + } + + return err; +} + +/* Throw an exception corresponding to error ERR. */ +static void inline +scm_locale_error (const char *func_name, int err) +{ + SCM s_err; + + s_err = scm_from_int (err); + scm_error (scm_system_error_key, func_name, + "Failed to install locale", + scm_cons (scm_strerror (s_err), SCM_EOL), + scm_cons (s_err, SCM_EOL)); +} + +/* Convenient macro to run STATEMENT in the locale context of C_LOCALE. */ +#define RUN_IN_LOCALE_SECTION(_c_locale, _statement) \ + do \ + { \ + int lsec_err; \ + scm_t_locale_settings lsec_prev_locale; \ + \ + lsec_err = enter_locale_section ((_c_locale), &lsec_prev_locale); \ + if (lsec_err) \ + scm_locale_error (FUNC_NAME, lsec_err); \ + else \ + { \ + _statement ; \ + \ + leave_locale_section (&lsec_prev_locale); \ + free_locale_settings (&lsec_prev_locale); \ + } \ + } \ + while (0) + +#endif /* !USE_GNU_LOCALE_API */ + +\f +/* Locale-dependent string comparison. */ + +/* Compare null-terminated strings C_S1 and C_S2 according to LOCALE. Return + an integer whose sign is the same as the difference between C_S1 and + C_S2. */ +static inline int +compare_strings (const char *c_s1, const char *c_s2, SCM locale, + const char *func_name) +#define FUNC_NAME func_name +{ + int result; + scm_t_locale c_locale; + + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (3, locale, c_locale); + + if (c_locale) + { +#ifdef USE_GNU_LOCALE_API + result = strcoll_l (c_s1, c_s2, c_locale); +#else +#ifdef HAVE_STRCOLL + RUN_IN_LOCALE_SECTION (c_locale, result = strcoll (c_s1, c_s2)); +#else + result = strcmp (c_s1, c_s2); +#endif +#endif /* !USE_GNU_LOCALE_API */ + } + else + +#ifdef HAVE_STRCOLL + result = strcoll (c_s1, c_s2); +#else + result = strcmp (c_s1, c_s2); +#endif + + return result; +} +#undef FUNC_NAME + +/* Store into DST an upper-case version of SRC. */ +static inline void +str_upcase (register char *dst, register const char *src) +{ + for (; *src != '\0'; src++, dst++) + *dst = toupper (*src); + *dst = '\0'; +} + +static inline void +str_downcase (register char *dst, register const char *src) +{ + for (; *src != '\0'; src++, dst++) + *dst = tolower (*src); + *dst = '\0'; +} + +#ifdef USE_GNU_LOCALE_API +static inline void +str_upcase_l (register char *dst, register const char *src, + scm_t_locale locale) +{ + for (; *src != '\0'; src++, dst++) + *dst = toupper_l (*src, locale); + *dst = '\0'; +} + +static inline void +str_downcase_l (register char *dst, register const char *src, + scm_t_locale locale) +{ + for (; *src != '\0'; src++, dst++) + *dst = tolower_l (*src, locale); + *dst = '\0'; +} +#endif + + +/* Compare null-terminated strings C_S1 and C_S2 in a case-independent way + according to LOCALE. Return an integer whose sign is the same as the + difference between C_S1 and C_S2. */ +static inline int +compare_strings_ci (const char *c_s1, const char *c_s2, SCM locale, + const char *func_name) +#define FUNC_NAME func_name +{ + int result; + scm_t_locale c_locale; + char *c_us1, *c_us2; + + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (3, locale, c_locale); + + c_us1 = (char *) alloca (strlen (c_s1) + 1); + c_us2 = (char *) alloca (strlen (c_s2) + 1); + + if (c_locale) + { +#ifdef USE_GNU_LOCALE_API + str_upcase_l (c_us1, c_s1, c_locale); + str_upcase_l (c_us2, c_s2, c_locale); + + result = strcoll_l (c_us1, c_us2, c_locale); +#else + int err; + scm_t_locale_settings prev_locale; + + err = enter_locale_section (c_locale, &prev_locale); + if (err) + { + scm_locale_error (func_name, err); + return 0; + } + + str_upcase (c_us1, c_s1); + str_upcase (c_us2, c_s2); + +#ifdef HAVE_STRCOLL + result = strcoll (c_us1, c_us2); +#else + result = strcmp (c_us1, c_us2); +#endif /* !HAVE_STRCOLL */ + + leave_locale_section (&prev_locale); + free_locale_settings (&prev_locale); +#endif /* !USE_GNU_LOCALE_API */ + } + else + { + str_upcase (c_us1, c_s1); + str_upcase (c_us2, c_s2); + +#ifdef HAVE_STRCOLL + result = strcoll (c_us1, c_us2); +#else + result = strcmp (c_us1, c_us2); +#endif + } + + return result; +} +#undef FUNC_NAME + + +SCM_DEFINE (scm_string_locale_lt, "string-locale<?", 2, 1, 0, + (SCM s1, SCM s2, SCM locale), + "Compare strings @var{s1} and @var{s2} in a locale-dependent way." + "If @var{locale} is provided, it should be locale object (as " + "returned by @code{make-locale}) and will be used to perform the " + "comparison; otherwise, the current system locale is used.") +#define FUNC_NAME s_scm_string_locale_lt +{ + int result; + const char *c_s1, *c_s2; + + SCM_VALIDATE_STRING (1, s1); + SCM_VALIDATE_STRING (2, s2); + + c_s1 = scm_i_string_chars (s1); + c_s2 = scm_i_string_chars (s2); + + result = compare_strings (c_s1, c_s2, locale, FUNC_NAME); + + scm_remember_upto_here_2 (s1, s2); + + return scm_from_bool (result < 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_string_locale_gt, "string-locale>?", 2, 1, 0, + (SCM s1, SCM s2, SCM locale), + "Compare strings @var{s1} and @var{s2} in a locale-dependent way." + "If @var{locale} is provided, it should be locale object (as " + "returned by @code{make-locale}) and will be used to perform the " + "comparison; otherwise, the current system locale is used.") +#define FUNC_NAME s_scm_string_locale_gt +{ + int result; + const char *c_s1, *c_s2; + + SCM_VALIDATE_STRING (1, s1); + SCM_VALIDATE_STRING (2, s2); + + c_s1 = scm_i_string_chars (s1); + c_s2 = scm_i_string_chars (s2); + + result = compare_strings (c_s1, c_s2, locale, FUNC_NAME); + + scm_remember_upto_here_2 (s1, s2); + + return scm_from_bool (result > 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_string_locale_ci_lt, "string-locale-ci<?", 2, 1, 0, + (SCM s1, SCM s2, SCM locale), + "Compare strings @var{s1} and @var{s2} in a case-insensitive, " + "and locale-dependent way. If @var{locale} is provided, it " + "should be locale object (as returned by @code{make-locale}) " + "and will be used to perform the comparison; otherwise, the " + "current system locale is used.") +#define FUNC_NAME s_scm_string_locale_ci_lt +{ + int result; + const char *c_s1, *c_s2; + + SCM_VALIDATE_STRING (1, s1); + SCM_VALIDATE_STRING (2, s2); + + c_s1 = scm_i_string_chars (s1); + c_s2 = scm_i_string_chars (s2); + + result = compare_strings_ci (c_s1, c_s2, locale, FUNC_NAME); + + scm_remember_upto_here_2 (s1, s2); + + return scm_from_bool (result < 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_string_locale_ci_gt, "string-locale-ci>?", 2, 1, 0, + (SCM s1, SCM s2, SCM locale), + "Compare strings @var{s1} and @var{s2} in a case-insensitive, " + "and locale-dependent way. If @var{locale} is provided, it " + "should be locale object (as returned by @code{make-locale}) " + "and will be used to perform the comparison; otherwise, the " + "current system locale is used.") +#define FUNC_NAME s_scm_string_locale_ci_gt +{ + int result; + const char *c_s1, *c_s2; + + SCM_VALIDATE_STRING (1, s1); + SCM_VALIDATE_STRING (2, s2); + + c_s1 = scm_i_string_chars (s1); + c_s2 = scm_i_string_chars (s2); + + result = compare_strings_ci (c_s1, c_s2, locale, FUNC_NAME); + + scm_remember_upto_here_2 (s1, s2); + + return scm_from_bool (result > 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_string_locale_ci_eq, "string-locale-ci=?", 2, 1, 0, + (SCM s1, SCM s2, SCM locale), + "Compare strings @var{s1} and @var{s2} in a case-insensitive, " + "and locale-dependent way. If @var{locale} is provided, it " + "should be locale object (as returned by @code{make-locale}) " + "and will be used to perform the comparison; otherwise, the " + "current system locale is used.") +#define FUNC_NAME s_scm_string_locale_ci_eq +{ + int result; + const char *c_s1, *c_s2; + + SCM_VALIDATE_STRING (1, s1); + SCM_VALIDATE_STRING (2, s2); + + c_s1 = scm_i_string_chars (s1); + c_s2 = scm_i_string_chars (s2); + + result = compare_strings_ci (c_s1, c_s2, locale, FUNC_NAME); + + scm_remember_upto_here_2 (s1, s2); + + return scm_from_bool (result == 0); +} +#undef FUNC_NAME + + +SCM_DEFINE (scm_char_locale_lt, "char-locale<?", 2, 1, 0, + (SCM c1, SCM c2, SCM locale), + "Return true if character @var{c1} is lower than @var{c2} " + "according to @var{locale} or to the current locale.") +#define FUNC_NAME s_scm_char_locale_lt +{ + char c_c1[2], c_c2[2]; + + SCM_VALIDATE_CHAR (1, c1); + SCM_VALIDATE_CHAR (2, c2); + + c_c1[0] = (char)SCM_CHAR (c1); c_c1[1] = '\0'; + c_c2[0] = (char)SCM_CHAR (c2); c_c2[1] = '\0'; + + return scm_from_bool (compare_strings (c_c1, c_c2, locale, FUNC_NAME) < 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_char_locale_gt, "char-locale>?", 2, 1, 0, + (SCM c1, SCM c2, SCM locale), + "Return true if character @var{c1} is greater than @var{c2} " + "according to @var{locale} or to the current locale.") +#define FUNC_NAME s_scm_char_locale_gt +{ + char c_c1[2], c_c2[2]; + + SCM_VALIDATE_CHAR (1, c1); + SCM_VALIDATE_CHAR (2, c2); + + c_c1[0] = (char)SCM_CHAR (c1); c_c1[1] = '\0'; + c_c2[0] = (char)SCM_CHAR (c2); c_c2[1] = '\0'; + + return scm_from_bool (compare_strings (c_c1, c_c2, locale, FUNC_NAME) > 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_char_locale_ci_lt, "char-locale-ci<?", 2, 1, 0, + (SCM c1, SCM c2, SCM locale), + "Return true if character @var{c1} is lower than @var{c2}, " + "in a case insensitive way according to @var{locale} or to " + "the current locale.") +#define FUNC_NAME s_scm_char_locale_ci_lt +{ + int result; + char c_c1[2], c_c2[2]; + + SCM_VALIDATE_CHAR (1, c1); + SCM_VALIDATE_CHAR (2, c2); + + c_c1[0] = (char)SCM_CHAR (c1); c_c1[1] = '\0'; + c_c2[0] = (char)SCM_CHAR (c2); c_c2[1] = '\0'; + + result = compare_strings_ci (c_c1, c_c2, locale, FUNC_NAME); + + return scm_from_bool (result < 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_char_locale_ci_gt, "char-locale-ci>?", 2, 1, 0, + (SCM c1, SCM c2, SCM locale), + "Return true if character @var{c1} is greater than @var{c2}, " + "in a case insensitive way according to @var{locale} or to " + "the current locale.") +#define FUNC_NAME s_scm_char_locale_ci_gt +{ + int result; + char c_c1[2], c_c2[2]; + + SCM_VALIDATE_CHAR (1, c1); + SCM_VALIDATE_CHAR (2, c2); + + c_c1[0] = (char)SCM_CHAR (c1); c_c1[1] = '\0'; + c_c2[0] = (char)SCM_CHAR (c2); c_c2[1] = '\0'; + + result = compare_strings_ci (c_c1, c_c2, locale, FUNC_NAME); + + return scm_from_bool (result > 0); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_char_locale_ci_eq, "char-locale-ci=?", 2, 1, 0, + (SCM c1, SCM c2, SCM locale), + "Return true if character @var{c1} is equal to @var{c2}, " + "in a case insensitive way according to @var{locale} or to " + "the current locale.") +#define FUNC_NAME s_scm_char_locale_ci_eq +{ + int result; + char c_c1[2], c_c2[2]; + + SCM_VALIDATE_CHAR (1, c1); + SCM_VALIDATE_CHAR (2, c2); + + c_c1[0] = (char)SCM_CHAR (c1); c_c1[1] = '\0'; + c_c2[0] = (char)SCM_CHAR (c2); c_c2[1] = '\0'; + + result = compare_strings_ci (c_c1, c_c2, locale, FUNC_NAME); + + return scm_from_bool (result == 0); +} +#undef FUNC_NAME + + +\f +/* Locale-dependent alphabetic character mapping. */ + +SCM_DEFINE (scm_char_locale_downcase, "char-locale-downcase", 1, 1, 0, + (SCM chr, SCM locale), + "Return the lowercase character that corresponds to @var{chr} " + "according to either @var{locale} or the current locale.") +#define FUNC_NAME s_scm_char_locale_downcase +{ + char c_chr; + int c_result; + scm_t_locale c_locale; + + SCM_VALIDATE_CHAR (1, chr); + c_chr = SCM_CHAR (chr); + + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (2, locale, c_locale); + + if (c_locale != NULL) + { +#ifdef USE_GNU_LOCALE_API + c_result = tolower_l (c_chr, c_locale); +#else + RUN_IN_LOCALE_SECTION (c_locale, c_result = tolower (c_chr)); +#endif + } + else + c_result = tolower (c_chr); + + return (SCM_MAKE_CHAR (c_result)); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_char_locale_upcase, "char-locale-upcase", 1, 1, 0, + (SCM chr, SCM locale), + "Return the uppercase character that corresponds to @var{chr} " + "according to either @var{locale} or the current locale.") +#define FUNC_NAME s_scm_char_locale_upcase +{ + char c_chr; + int c_result; + scm_t_locale c_locale; + + SCM_VALIDATE_CHAR (1, chr); + c_chr = SCM_CHAR (chr); + + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (2, locale, c_locale); + + if (c_locale != NULL) + { +#ifdef USE_GNU_LOCALE_API + c_result = toupper_l (c_chr, c_locale); +#else + RUN_IN_LOCALE_SECTION (c_locale, c_result = toupper (c_chr)); +#endif + } + else + c_result = toupper (c_chr); + + return (SCM_MAKE_CHAR (c_result)); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_string_locale_upcase, "string-locale-upcase", 1, 1, 0, + (SCM str, SCM locale), + "Return a new string that is the uppercase version of " + "@var{str} according to either @var{locale} or the current " + "locale.") +#define FUNC_NAME s_scm_string_locale_upcase +{ + const char *c_str; + char *c_ustr; + scm_t_locale c_locale; + + SCM_VALIDATE_STRING (1, str); + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (2, locale, c_locale); + + c_str = scm_i_string_chars (str); + c_ustr = (char *) alloca (strlen (c_str) + 1); + + if (c_locale) + { +#ifdef USE_GNU_LOCALE_API + str_upcase_l (c_ustr, c_str, c_locale); +#else + RUN_IN_LOCALE_SECTION (c_locale, str_upcase (c_ustr, c_str)); +#endif + } + else + str_upcase (c_ustr, c_str); + + scm_remember_upto_here (str); + + return (scm_from_locale_string (c_ustr)); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_string_locale_downcase, "string-locale-downcase", 1, 1, 0, + (SCM str, SCM locale), + "Return a new string that is the down-case version of " + "@var{str} according to either @var{locale} or the current " + "locale.") +#define FUNC_NAME s_scm_string_locale_downcase +{ + const char *c_str; + char *c_lstr; + scm_t_locale c_locale; + + SCM_VALIDATE_STRING (1, str); + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (2, locale, c_locale); + + c_str = scm_i_string_chars (str); + c_lstr = (char *) alloca (strlen (c_str) + 1); + + if (c_locale) + { +#ifdef USE_GNU_LOCALE_API + str_downcase_l (c_lstr, c_str, c_locale); +#else + RUN_IN_LOCALE_SECTION (c_locale, str_downcase (c_lstr, c_str)); +#endif + } + else + str_downcase (c_lstr, c_str); + + scm_remember_upto_here (str); + + return (scm_from_locale_string (c_lstr)); +} +#undef FUNC_NAME + +/* Note: We don't provide mutative versions of `string-locale-(up|down)case' + because, in some languages, a single downcase character maps to a couple + of uppercase characters. Read the SRFI-13 document for a detailed + discussion about this. */ + + +\f +/* Locale-dependent number parsing. */ + +SCM_DEFINE (scm_locale_string_to_integer, "locale-string->integer", + 1, 2, 0, (SCM str, SCM base, SCM locale), + "Convert string @var{str} into an integer according to either " + "@var{locale} (a locale object as returned by @code{make-locale}) " + "or the current process locale. Return two values: an integer " + "(on success) or @code{#f}, and the number of characters read " + "from @var{str} (@code{0} on failure).") +#define FUNC_NAME s_scm_locale_string_to_integer +{ + SCM result; + long c_result; + int c_base; + const char *c_str; + char *c_endptr; + scm_t_locale c_locale; + + SCM_VALIDATE_STRING (1, str); + c_str = scm_i_string_chars (str); + + if (base != SCM_UNDEFINED) + SCM_VALIDATE_INT_COPY (2, base, c_base); + else + c_base = 10; + + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (3, locale, c_locale); + + if (c_locale != NULL) + { +#ifdef USE_GNU_LOCALE_API + c_result = strtol_l (c_str, &c_endptr, c_base, c_locale); +#else + RUN_IN_LOCALE_SECTION (c_locale, + c_result = strtol (c_str, &c_endptr, c_base)); +#endif + } + else + c_result = strtol (c_str, &c_endptr, c_base); + + scm_remember_upto_here (str); + + if (c_endptr == c_str) + result = SCM_BOOL_F; + else + result = scm_from_long (c_result); + + return (scm_values (scm_list_2 (result, scm_from_long (c_endptr - c_str)))); +} +#undef FUNC_NAME + +SCM_DEFINE (scm_locale_string_to_inexact, "locale-string->inexact", + 1, 1, 0, (SCM str, SCM locale), + "Convert string @var{str} into an inexact number according to " + "either @var{locale} (a locale object as returned by " + "@code{make-locale}) or the current process locale. Return " + "two values: an inexact number (on success) or @code{#f}, and " + "the number of characters read from @var{str} (@code{0} on " + "failure).") +#define FUNC_NAME s_scm_locale_string_to_inexact +{ + SCM result; + double c_result; + const char *c_str; + char *c_endptr; + scm_t_locale c_locale; + + SCM_VALIDATE_STRING (1, str); + c_str = scm_i_string_chars (str); + + SCM_VALIDATE_OPTIONAL_LOCALE_COPY (2, locale, c_locale); + + if (c_locale != NULL) + { +#ifdef USE_GNU_LOCALE_API + c_result = strtod_l (c_str, &c_endptr, c_locale); +#else + RUN_IN_LOCALE_SECTION (c_locale, + c_result = strtod (c_str, &c_endptr)); +#endif + } + else + c_result = strtod (c_str, &c_endptr); + + scm_remember_upto_here (str); + + if (c_endptr == c_str) + result = SCM_BOOL_F; + else + result = scm_from_double (c_result); + + return (scm_values (scm_list_2 (result, scm_from_long (c_endptr - c_str)))); +} +#undef FUNC_NAME + + +\f +void +scm_init_i18n () +{ + scm_add_feature ("ice-9-i18n"); + +#define _SCM_STRINGIFY_LC(_name) # _name +#define SCM_STRINGIFY_LC(_name) _SCM_STRINGIFY_LC (_name) + + /* Define all the relevant `_MASK' variables. */ +#define SCM_DEFINE_LOCALE_CATEGORY(_name) \ + scm_c_define ("LC_" SCM_STRINGIFY_LC (_name) "_MASK", \ + SCM_I_MAKINUM (LC_ ## _name ## _MASK)); +#include "locale-categories.h" + +#undef SCM_DEFINE_LOCALE_CATEGORY +#undef SCM_STRINGIFY_LC +#undef _SCM_STRINGIFY_LC + + scm_c_define ("LC_ALL_MASK", SCM_I_MAKINUM (LC_ALL_MASK)); + +#include "libguile/i18n.x" + +#ifndef USE_GNU_LOCALE_API + scm_set_smob_mark (scm_tc16_locale_smob_type, smob_locale_mark); +#endif +} + + +/* + Local Variables: + c-file-style: "gnu" + End: +*/ --- /dev/null +++ mod/libguile/i18n.h @@ -0,0 +1,52 @@ +/* classes: h_files */ + +#ifndef SCM_I18N_H +#define SCM_I18N_H + +/* Copyright (C) 2006 Free Software Foundation, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libguile/__scm.h" + +SCM_API SCM scm_make_locale (SCM category_mask, SCM locale_name, SCM base_locale); +SCM_API SCM scm_locale_p (SCM obj); +SCM_API SCM scm_string_locale_lt (SCM s1, SCM s2, SCM locale); +SCM_API SCM scm_string_locale_gt (SCM s1, SCM s2, SCM locale); +SCM_API SCM scm_string_locale_ci_lt (SCM s1, SCM s2, SCM locale); +SCM_API SCM scm_string_locale_ci_gt (SCM s1, SCM s2, SCM locale); +SCM_API SCM scm_string_locale_ci_eq (SCM s1, SCM s2, SCM locale); +SCM_API SCM scm_char_locale_lt (SCM c1, SCM c2, SCM locale); +SCM_API SCM scm_char_locale_gt (SCM c1, SCM c2, SCM locale); +SCM_API SCM scm_char_locale_ci_lt (SCM c1, SCM c2, SCM locale); +SCM_API SCM scm_char_locale_ci_gt (SCM c1, SCM c2, SCM locale); +SCM_API SCM scm_char_locale_ci_eq (SCM c1, SCM c2, SCM locale); +SCM_API SCM scm_char_locale_upcase (SCM chr, SCM locale); +SCM_API SCM scm_char_locale_downcase (SCM chr, SCM locale); +SCM_API SCM scm_string_locale_upcase (SCM chr, SCM locale); +SCM_API SCM scm_string_locale_downcase (SCM chr, SCM locale); +SCM_API SCM scm_locale_string_to_integer (SCM str, SCM base, SCM locale); +SCM_API SCM scm_locale_string_to_inexact (SCM str, SCM locale); + +SCM_API void scm_init_i18n (void); + +#endif /* SCM_I18N_H */ + +/* + Local Variables: + c-file-style: "gnu" + End: +*/ --- /dev/null +++ mod/libguile/locale-categories.h @@ -0,0 +1,47 @@ +/* Copyright (C) 2006 Free Software Foundation, Inc. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* A list of all available locale categories, not including `ALL'. */ + + +/* The six standard categories, as defined in IEEE Std 1003.1-2001. */ +SCM_DEFINE_LOCALE_CATEGORY (COLLATE) +SCM_DEFINE_LOCALE_CATEGORY (CTYPE) +SCM_DEFINE_LOCALE_CATEGORY (MESSAGES) +SCM_DEFINE_LOCALE_CATEGORY (MONETARY) +SCM_DEFINE_LOCALE_CATEGORY (NUMERIC) +SCM_DEFINE_LOCALE_CATEGORY (TIME) + +/* Additional non-standard categories. */ +#ifdef LC_PAPER +SCM_DEFINE_LOCALE_CATEGORY (PAPER) +#endif +#ifdef LC_NAME +SCM_DEFINE_LOCALE_CATEGORY (NAME) +#endif +#ifdef LC_ADDRESS +SCM_DEFINE_LOCALE_CATEGORY (ADDRESS) +#endif +#ifdef LC_TELEPHONE +SCM_DEFINE_LOCALE_CATEGORY (TELEPHONE) +#endif +#ifdef LC_MEASUREMENT +SCM_DEFINE_LOCALE_CATEGORY (MEASUREMENT) +#endif +#ifdef LC_IDENTIFICATION +SCM_DEFINE_LOCALE_CATEGORY (IDENTIFICATION) +#endif --- /dev/null +++ mod/test-suite/tests/.arch-ids/i18n.test.id @@ -0,0 +1 @@ +Ludovic Courtes <ludovic.courtes@laas.fr> Thu Oct 19 01:46:26 2006 25287.0 --- /dev/null +++ mod/test-suite/tests/i18n.test @@ -0,0 +1,143 @@ +;;;; i18n.test --- Exercise the i18n API. +;;;; +;;;; Copyright (C) 2006 Free Software Foundation, Inc. +;;;; Ludovic Courtès +;;;; +;;;; This library is free software; you can redistribute it and/or +;;;; modify it under the terms of the GNU Lesser General Public +;;;; License as published by the Free Software Foundation; either +;;;; version 2.1 of the License, or (at your option) any later version. +;;;; +;;;; This library is distributed in the hope that it will be useful, +;;;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;;;; Lesser General Public License for more details. +;;;; +;;;; You should have received a copy of the GNU Lesser General Public +;;;; License along with this library; if not, write to the Free Software +;;;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + +(define-module (test-suite i18n) + :use-module (ice-9 i18n) + :use-module (test-suite lib)) + +;; Start from a pristine locale state. +(setlocale LC_ALL "C") + +\f +(with-test-prefix "locale objects" + + (pass-if "make-locale (2 args)" + (not (not (make-locale LC_ALL_MASK "C")))) + + (pass-if "make-locale (3 args)" + (not (not (make-locale LC_COLLATE_MASK "C" + (make-locale LC_MESSAGES_MASK "C"))))) + + (pass-if "locale?" + (and (locale? (make-locale LC_ALL_MASK "C")) + (locale? (make-locale (logior LC_MESSAGES_MASK LC_NUMERIC_MASK) "C" + (make-locale LC_CTYPE_MASK "C")))))) + + +\f +(with-test-prefix "text collation (English)" + + (pass-if "string-locale<?" + (and (string-locale<? "hello" "world") + (string-locale<? "hello" "world" + (make-locale LC_COLLATE_MASK "C")))) + + (pass-if "char-locale<?" + (and (char-locale<? #\a #\b) + (char-locale<? #\a #\b (make-locale LC_COLLATE_MASK "C")))) + + (pass-if "string-locale-ci=?" + (and (string-locale-ci=? "Hello" "HELLO") + (string-locale-ci=? "Hello" "HELLO" + (make-locale LC_COLLATE_MASK "C")))) + + (pass-if "string-locale-ci<?" + (and (string-locale-ci<? "hello" "WORLD") + (string-locale-ci<? "hello" "WORLD" + (make-locale LC_COLLATE_MASK "C"))))) + +\f +(define %french-locale + (false-if-exception + (make-locale (logior LC_CTYPE_MASK LC_COLLATE_MASK) + "fr_FR.ISO-8859-1"))) + +(define (under-french-locale-or-unresolved thunk) + ;; On non-GNU systems, an exception may be raised only when the locale is + ;; actually used rather than at `make-locale'-time. Thus, we must guard + ;; against both. + (if %french-locale + (catch 'system-error thunk + (lambda (key . args) + (throw 'unresolved))) + (throw 'unresolved))) + +(with-test-prefix "text collation (French)" + + (pass-if "string-locale<?" + (under-french-locale-or-unresolved + (lambda () + (string-locale<? "été" "hiver" %french-locale)))) + + (pass-if "char-locale<?" + (under-french-locale-or-unresolved + (lambda () + (char-locale<? #\é #\h %french-locale)))) + + (pass-if "string-locale-ci=?" + (under-french-locale-or-unresolved + (lambda () + (string-locale-ci=? "ÉTÉ" "été" %french-locale)))) + + (pass-if "string-locale-ci<>?" + (under-french-locale-or-unresolved + (lambda () + (and (string-locale-ci<? "été" "Hiver" %french-locale) + (string-locale-ci>? "HiVeR" "été" %french-locale))))) + + (pass-if "char-locale-ci<>?" + (under-french-locale-or-unresolved + (lambda () + (and (char-locale-ci<? #\é #\H %french-locale) + (char-locale-ci>? #\h #\É %french-locale)))))) + +\f +(with-test-prefix "character mapping" + + (pass-if "char-locale-downcase" + (and (eq? #\a (char-locale-downcase #\A)) + (eq? #\a (char-locale-downcase #\A (make-locale LC_ALL_MASK "C"))))) + + (pass-if "char-locale-upcase" + (and (eq? #\Z (char-locale-upcase #\z)) + (eq? #\Z (char-locale-upcase #\z (make-locale LC_ALL_MASK "C")))))) + +\f +(with-test-prefix "number parsing" + + (pass-if "locale-string->integer" + (call-with-values (lambda () (locale-string->integer "123")) + (lambda (result char-count) + (and (equal? result 123) + (equal? char-count 3))))) + + (pass-if "locale-string->inexact" + (call-with-values + (lambda () + (locale-string->inexact "123.456" + (make-locale LC_NUMERIC_MASK "C"))) + (lambda (result char-count) + (and (equal? result 123.456) + (equal? char-count 7)))))) + + +;;; Local Variables: +;;; coding: latin-1 +;;; mode: scheme +;;; End: [-- Attachment #3: Type: text/plain, Size: 143 bytes --] _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-22 18:33 ` Ludovic Courtès @ 2006-10-23 2:01 ` Rob Browning 2006-10-23 7:56 ` Ludovic Courtès 2006-10-25 18:33 ` Neil Jerram ` (4 subsequent siblings) 5 siblings, 1 reply; 46+ messages in thread From: Rob Browning @ 2006-10-23 2:01 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > On IRC, Rob identified a number of issues with this approach: > > * It would be the first `ice-9' module that does a `dynamic-link', so > we may want to think twice before doing it. > > * The C programmer willing to use those functions would have to link > against `libguile-i18n' additionally. Yes, the main question is to what extent we want people coding in C to have to link aginst libraries other than -lguile. Of course, this is already the case for some of the SRFIs. > There's another (small) issue: > > * The online help is a bit confused because the doc of the i18n.c > functions is include in libguile's `guile-procedure.txt'. Thus, > `(help make-locale)' always works, even when `(ice-9 i18n)' is not > loaded. Perhaps that's something we'll eventually want to fix in the documentation system, but a really simple approach might be to just mention the required module in the documentation for each function. > While I agree that this practically precludes use of those functions > by C programmers (as is the case for those SRFIs that are > implemented in C) Actually, if I understand you correctly, this isn't the case. The SRFIs (which provide C interfaces) are definitely intended for use by C programmers. The programmers just have to make sure to include the correct -lguile-srfi-* for the SRFI in question. Although I'm not sure it's a great idea, one other possibility would be to put the C code in libguile, and to provide a C init function, called from init.c, that doesn't do anything more than publish a scheme-side init function that can handle the full initialization later. Then the startup process should be relatively unaffected, and ice-9/i18n.scm would just do something like this: (define-module (ice-9 i18n) ...) (scm-init-i18n) This would avoid the need to make it possible to use dynamic-link for items that are already in libguile. Of course, whether or not the approach is a good idea is a different question. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-23 2:01 ` Rob Browning @ 2006-10-23 7:56 ` Ludovic Courtès 2006-10-24 8:37 ` Rob Browning 0 siblings, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-10-23 7:56 UTC (permalink / raw) Cc: Guile-Devel Hi, Rob Browning <rlb@defaultvalue.org> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: > >> While I agree that this practically precludes use of those functions >> by C programmers (as is the case for those SRFIs that are >> implemented in C) > > Actually, if I understand you correctly, this isn't the case. The > SRFIs (which provide C interfaces) are definitely intended for use by > C programmers. The programmers just have to make sure to include the > correct -lguile-srfi-* for the SRFI in question. I don't think this is actually the case: there are currently 4 shared libraries in the `srfi' directory, but none of them is documented in the manual and the C functions they export are not mentioned either (that's what I meant by "practically preclude": it's technically possible to use them but it's not documented). I would expect it to be done on purpose: For instance, the contents of `libguile-srfi-srfi-1' changed noticeably as some functions were rewritten in C and this is not something we want users to be aware of. > Then the startup process should be relatively unaffected, and > ice-9/i18n.scm would just do something like this: > > (define-module (ice-9 i18n) ...) > (scm-init-i18n) Yes, I'm open to that if we consider it a better option than having another shared lib. The issue, IMO, is that this is not very "scalable" either: we still end up adding one function call in `scm_i_init_guile ()' that systematically gets in the way. > This would avoid the need to make it possible to use dynamic-link for > items that are already in libguile. Of course, whether or not the > approach is a good idea is a different question. Right. What I had in mind was to have, say, `(dynamic-link)' (with no arguments) translate to `lt_dlopen (NULL)', so that we could access symbols contained within the executable. Now, I'm not sure this would work in all cases, for instance when the executable is not `guile' itself. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-23 7:56 ` Ludovic Courtès @ 2006-10-24 8:37 ` Rob Browning 2006-10-25 8:16 ` Ludovic Courtès 2006-10-25 18:43 ` Neil Jerram 0 siblings, 2 replies; 46+ messages in thread From: Rob Browning @ 2006-10-24 8:37 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > I don't think this is actually the case: there are currently 4 > shared libraries in the `srfi' directory, but none of them is > documented in the manual and the C functions they export are not > mentioned either (that's what I meant by "practically preclude": > it's technically possible to use them but it's not documented). Actually, in general, the SRFI scm_* functions are intended for public use. If not, then all of the relevant scm_* functions would/should have been named scm_i_*. Also, you definitely can't judge by the presence or lack of documentation. Guile's documentation has often taken a while to catch up with the code. (BTW, does documentation snarfing work right for C functions in libraries outside libguile? If not, then that's just a bug.) > I would expect it to be done on purpose: For instance, the contents > of `libguile-srfi-srfi-1' changed noticeably as some functions were > rewritten in C and this is not something we want users to be aware > of. Note that when Marius moved the SRFI-13 and SRFI-14 functions to libguile, he still kept the C library for backward compatibility. I believe this was specifically so that people who were already using those functions wouldn't be affected. > Yes, I'm open to that if we consider it a better option than having > another shared lib. > > The issue, IMO, is that this is not very "scalable" either: we still > end up adding one function call in `scm_i_init_guile ()' that > systematically gets in the way. I'm actually not sure which (of the discussed approaches) I think is best. I suppose first we'd need to consider the extent to which we want to move toward a more modular ice-9 (more modular core), and then determine how we might want to implement that modularity. > Right. What I had in mind was to have, say, `(dynamic-link)' (with > no arguments) translate to `lt_dlopen (NULL)', so that we could > access symbols contained within the executable. Now, I'm not sure > this would work in all cases, for instance when the executable is > not `guile' itself. Well, if we wanted to take this approach, and if lt_dlopen(NULL) wouldn't do what was intended, perhaps there is some other way to accomplish the same thing (i.e. to make sure you get the current libguile.so), but I don't know offhand. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-24 8:37 ` Rob Browning @ 2006-10-25 8:16 ` Ludovic Courtès 2006-10-25 8:46 ` Rob Browning 2006-10-25 18:43 ` Neil Jerram 1 sibling, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-10-25 8:16 UTC (permalink / raw) Cc: Guile-Devel Hi, Rob Browning <rlb@defaultvalue.org> writes: > (BTW, does documentation snarfing work right for C functions in > libraries outside libguile? If not, then that's just a bug.) No, it doesn't work. In the latest `guile-reader', I have a couple of modules that do (part of) what the Awk script in `libguile' does: parsing the output of `cpp -DSCM_MAGIC_SNARF'. I'd be in favor of integrating such an approach in Guile core eventually. >> The issue, IMO, is that this is not very "scalable" either: we still >> end up adding one function call in `scm_i_init_guile ()' that >> systematically gets in the way. > > I'm actually not sure which (of the discussed approaches) I think is > best. I suppose first we'd need to consider the extent to which we > want to move toward a more modular ice-9 (more modular core), and then > determine how we might want to implement that modularity. Personally, I would like Guile "core" to be much more modular than what it is now. I believe many things in what we call "Guile core" are there just because we want them to be part of the "standard Guile library", but they certainly to not comprise the "core" or "kernel" of Guile. For instance, I believe the Gettext-related functions ought to be distributed with Guile core but as a separate module. Same for SRFI-1[43]. Not to mention the bits and pieces that are in `boot-9' and that happen to be visible to everyone. ;-) Basically, the logical separation among the R5.91RS standard libraries has a level of granularity that looks appropriate to me. Now, whether each module should load its own shared library is a different issue. This may depend on the module characteristics: size, usefulness, C programmability. We also have to find a balance between lazy initialization (with `dynamic-link') and systematic initialization. Getting back to `(ice-9 i18n)': I'm strongly in favor of keeping this as a module; I am more inclined to having it in a separate shared library (because it's not useful to everyone) but I wouldn't mind having it in `libguile.so'. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-25 8:16 ` Ludovic Courtès @ 2006-10-25 8:46 ` Rob Browning 2006-10-25 18:40 ` Neil Jerram 0 siblings, 1 reply; 46+ messages in thread From: Rob Browning @ 2006-10-25 8:46 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > No, it doesn't work. In the latest `guile-reader', I have a couple of > modules that do (part of) what the Awk script in `libguile' does: > parsing the output of `cpp -DSCM_MAGIC_SNARF'. I'd be in favor of > integrating such an approach in Guile core eventually. Yes. It would be nice to have a more comprehensive solution for documentation, one that can be used both internally and externally. > Personally, I would like Guile "core" to be much more modular than what > it is now. I believe many things in what we call "Guile core" are there > just because we want them to be part of the "standard Guile library", > but they certainly to not comprise the "core" or "kernel" of Guile. For > instance, I believe the Gettext-related functions ought to be > distributed with Guile core but as a separate module. Same for > SRFI-1[43]. Not to mention the bits and pieces that are in `boot-9' and > that happen to be visible to everyone. ;-) I don't really disagree. In particular, I think this is something we should definitely consider as we examine R6RS. > Now, whether each module should load its own shared library is a > different issue. This may depend on the module characteristics: > size, usefulness, C programmability. We also have to find a balance > between lazy initialization (with `dynamic-link') and systematic > initialization. > > Getting back to `(ice-9 i18n)': I'm strongly in favor of keeping this as > a module; I am more inclined to having it in a separate shared library > (because it's not useful to everyone) but I wouldn't mind having it in > `libguile.so'. I'm somewhat inclined to think that the scheme-side module is a good idea, though perhaps it begs more general organizational questions. I'm less certain about whether or not adding small shared library is a good idea. However, in both cases, I need to think a bit more. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-25 8:46 ` Rob Browning @ 2006-10-25 18:40 ` Neil Jerram 2006-10-25 19:55 ` Rob Browning 2006-10-26 8:47 ` Ludovic Courtès 0 siblings, 2 replies; 46+ messages in thread From: Neil Jerram @ 2006-10-25 18:40 UTC (permalink / raw) Cc: Guile-Devel Rob Browning <rlb@defaultvalue.org> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: > >> No, it doesn't work. In the latest `guile-reader', I have a couple of >> modules that do (part of) what the Awk script in `libguile' does: >> parsing the output of `cpp -DSCM_MAGIC_SNARF'. I'd be in favor of >> integrating such an approach in Guile core eventually. > > Yes. It would be nice to have a more comprehensive solution for > documentation, one that can be used both internally and externally. FWIW, this is the next thing on my radar, once I'm done with debugging stuff. Not that that should stop anyone beating me to it! >> Personally, I would like Guile "core" to be much more modular than what >> it is now. Me too. And I think this should mean separate libraries. > I don't really disagree. In particular, I think this is something we > should definitely consider as we examine R6RS. Ah yes, R6RS. I've been following r6rs-discuss just enough to feel worried about this! (My impression is that there's quite a lot of change from R5RS, not just additions.) >> Getting back to `(ice-9 i18n)': I'm strongly in favor of keeping this as >> a module; I am more inclined to having it in a separate shared library >> (because it's not useful to everyone) but I wouldn't mind having it in >> `libguile.so'. > > I'm somewhat inclined to think that the scheme-side module is a good > idea, though perhaps it begs more general organizational questions. > I'm less certain about whether or not adding small shared library is a > good idea. However, in both cases, I need to think a bit more. I agree with both separate module and separate library. If having a separate library throws up problems, this can motivate us to address them. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-25 18:40 ` Neil Jerram @ 2006-10-25 19:55 ` Rob Browning 2006-10-26 8:47 ` Ludovic Courtès 1 sibling, 0 replies; 46+ messages in thread From: Rob Browning @ 2006-10-25 19:55 UTC (permalink / raw) Cc: Guile-Devel Neil Jerram <neil@ossau.uklinux.net> writes: >>> Personally, I would like Guile "core" to be much more modular than >>> what it is now. > > Me too. And I think this should mean separate libraries. > >> I don't really disagree. In particular, I think this is something we >> should definitely consider as we examine R6RS. > > Ah yes, R6RS. I've been following r6rs-discuss just enough to feel > worried about this! (My impression is that there's quite a lot of > change from R5RS, not just additions.) Although I still haven't looked at R6RS carefully yet, I've been wondering if this might be an opportunity to think about a Guile 2.0 release, one where we give ourselves more latitude to make disruptive changes, perhaps including R6RS support, the addition of any other major features, and any appropriate reorganizations (ice-9?). -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-25 18:40 ` Neil Jerram 2006-10-25 19:55 ` Rob Browning @ 2006-10-26 8:47 ` Ludovic Courtès 2006-11-09 7:44 ` Ludovic Courtès 1 sibling, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-10-26 8:47 UTC (permalink / raw) Cc: Guile-Devel, Rob Browning Hi, Neil Jerram <neil@ossau.uklinux.net> writes: > I agree with both separate module and separate library. If having a > separate library throws up problems, this can motivate us to address > them. In particular, if we keep it this way for `(ice-9 i18n)', do you think we should document both the existence of `libguile-i18n-vXX' and the C functions that are in this library? The patch I posted only documents the Scheme side, assuming that the C side is "not very useful" (which is debatable). Rob pointed out that since we do have those C functions anyway, then there's no compelling reason not to document them. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-26 8:47 ` Ludovic Courtès @ 2006-11-09 7:44 ` Ludovic Courtès 2006-11-09 17:43 ` Rob Browning 0 siblings, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-11-09 7:44 UTC (permalink / raw) Cc: Guile-Devel, Rob Browning Hi, If nobody disagrees, I would like to merge `(ice-9 i18n)' in HEAD and 1.8 within a few days "as is" (that is, using a separate shared library and without documenting the C functions, as discussed earlier). Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-09 7:44 ` Ludovic Courtès @ 2006-11-09 17:43 ` Rob Browning 2006-11-10 13:39 ` Ludovic Courtès 0 siblings, 1 reply; 46+ messages in thread From: Rob Browning @ 2006-11-09 17:43 UTC (permalink / raw) Cc: Guile-Devel ludovic.courtes@laas.fr (Ludovic Courtès) writes: > If nobody disagrees, I would like to merge `(ice-9 i18n)' in HEAD > and 1.8 within a few days "as is" (that is, using a separate shared > library and without documenting the C functions, as discussed > earlier). I don't have a strong feeling about the shared library issue as long as none of the versioning requirements are broken. However, I'm still opposed to the addition of new scm_ functions that aren't intended to be public, but don't use the scm_i_ prefix. For better or for worse, people have long been advised to look at the Guile headers/source in addition to the documentation, especially when the documentation wasn't as good, and they've also been told about the scm_i_ convention. I've assumed that convention myself when reading the source, and whether we maintain a public/private distinction via a naming convention or via public/private headers, I think it's a good idea. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-09 17:43 ` Rob Browning @ 2006-11-10 13:39 ` Ludovic Courtès 2006-11-11 15:17 ` Neil Jerram 2006-11-20 13:24 ` Ludovic Courtès 0 siblings, 2 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-11-10 13:39 UTC (permalink / raw) Cc: Guile-Devel, Neil Jerram Hi, Rob Browning <rlb@defaultvalue.org> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: > >> If nobody disagrees, I would like to merge `(ice-9 i18n)' in HEAD >> and 1.8 within a few days "as is" (that is, using a separate shared >> library and without documenting the C functions, as discussed >> earlier). > > I don't have a strong feeling about the shared library issue as long > as none of the versioning requirements are broken. However, I'm still > opposed to the addition of new scm_ functions that aren't intended to > be public, but don't use the scm_i_ prefix. Fair enough. Then I think I'll do the following: 1. Keep the shared library (named `libguile-i18n-v-0' in the next 1.8 release). 2. Document its existence as well as the C functions. I think it's a better plan than renaming the C functions to `scm_i_'. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-10 13:39 ` Ludovic Courtès @ 2006-11-11 15:17 ` Neil Jerram 2006-11-20 13:24 ` Ludovic Courtès 1 sibling, 0 replies; 46+ messages in thread From: Neil Jerram @ 2006-11-11 15:17 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > Fair enough. Then I think I'll do the following: > > 1. Keep the shared library (named `libguile-i18n-v-0' in the next 1.8 > release). > > 2. Document its existence as well as the C functions. > > I think it's a better plan than renaming the C functions to `scm_i_'. FWIW I'm happy with that. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-10 13:39 ` Ludovic Courtès 2006-11-11 15:17 ` Neil Jerram @ 2006-11-20 13:24 ` Ludovic Courtès 2006-11-21 22:03 ` Neil Jerram 1 sibling, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-11-20 13:24 UTC (permalink / raw) Cc: Guile-Devel, Neil Jerram Hi, ludovic.courtes@laas.fr (Ludovic Courtès) writes: > Fair enough. Then I think I'll do the following: > > 1. Keep the shared library (named `libguile-i18n-v-0' in the next 1.8 > release). > > 2. Document its existence as well as the C functions. This is now in HEAD. I'm planning to merge it in 1.8 some time soon. Please report build/run-time problems, especially on non-GNU platforms. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-20 13:24 ` Ludovic Courtès @ 2006-11-21 22:03 ` Neil Jerram 2006-11-22 13:38 ` Ludovic Courtès 0 siblings, 1 reply; 46+ messages in thread From: Neil Jerram @ 2006-11-21 22:03 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > This is now in HEAD. Great! > I'm planning to merge it in 1.8 some time soon. I'm not sure that's a good idea, as will be apparent from another thread. Can I suggest holding off until that other thread reaches a consensus? Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-21 22:03 ` Neil Jerram @ 2006-11-22 13:38 ` Ludovic Courtès 0 siblings, 0 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-11-22 13:38 UTC (permalink / raw) Cc: Guile-Devel Neil Jerram <neil@ossau.uklinux.net> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: >> I'm planning to merge it in 1.8 some time soon. > > I'm not sure that's a good idea, as will be apparent from another > thread. Can I suggest holding off until that other thread reaches a > consensus? Sure. ;-) Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-24 8:37 ` Rob Browning 2006-10-25 8:16 ` Ludovic Courtès @ 2006-10-25 18:43 ` Neil Jerram 2006-10-25 19:31 ` Rob Browning 1 sibling, 1 reply; 46+ messages in thread From: Neil Jerram @ 2006-10-25 18:43 UTC (permalink / raw) Cc: Guile-Devel Rob Browning <rlb@defaultvalue.org> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: > >> I don't think this is actually the case: there are currently 4 >> shared libraries in the `srfi' directory, but none of them is >> documented in the manual and the C functions they export are not >> mentioned either (that's what I meant by "practically preclude": >> it's technically possible to use them but it's not documented). > > Actually, in general, the SRFI scm_* functions are intended for public > use. If not, then all of the relevant scm_* functions would/should > have been named scm_i_*. > > Also, you definitely can't judge by the presence or lack of > documentation. Guile's documentation has often taken a while to catch > up with the code. I'm not sure I agree with that. I accept that documentation can sometimes take a while to catch up (although it shouldn't, and recently I think we've all been pretty good about writing doc at the same time as developing something), but in principle I think "presence in the manual" is a better way of indicating to users whether an API is officially supported than a coding convention. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-25 18:43 ` Neil Jerram @ 2006-10-25 19:31 ` Rob Browning 0 siblings, 0 replies; 46+ messages in thread From: Rob Browning @ 2006-10-25 19:31 UTC (permalink / raw) Cc: Guile-Devel Neil Jerram <neil@ossau.uklinux.net> writes: >> Also, you definitely can't judge by the presence or lack of >> documentation. Guile's documentation has often taken a while to >> catch up with the code. > > I'm not sure I agree with that. I accept that documentation can > sometimes take a while to catch up (although it shouldn't, and > recently I think we've all been pretty good about writing doc at the > same time as developing something), but in principle I think > "presence in the manual" is a better way of indicating to users > whether an API is officially supported than a coding convention. Well, if that's how we want to proceed, then I think we need to be very clear about it. My understanding has been that we promse that as a default, any C feature that's prefixed with scm_ instead of scm_i_ is fair game for the C programmer and that they can expect us to maintain it going forward (plus or minus deprecation, *major* (i.e. 2.0) releases, etc.). In the past (at least), this was important because there were a lot of things not mentioned in the documentation. Further, as with the SRFI code, the automatic documentation mechanism hasn't included the C documentation, even when it exists, and even if our documentation becomes (has become) more or less comprehensive, I still feel like the scm_ vs scm_i_ convention is a good one. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-22 18:33 ` Ludovic Courtès 2006-10-23 2:01 ` Rob Browning @ 2006-10-25 18:33 ` Neil Jerram 2006-10-26 8:39 ` Ludovic Courtès 2006-11-29 23:08 ` Kevin Ryde ` (3 subsequent siblings) 5 siblings, 1 reply; 46+ messages in thread From: Neil Jerram @ 2006-10-25 18:33 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > Hi, Hi, and sorry for coming late to the discussion. I think this whole patch is great. I've a few detailed comments below, and I'll comment on some of the conceptual issues in response to emails further down the thread. > @c Local Variables: > @c TeX-master: "guile.texi" > +@c ispell-local-dictionary: "american" Hmmm :-) (I'm British.) I guess Guile is an FSF project, and the FSF is US, though, so OK. > -void > -scm_init_i18n () > +void > +scm_init_gettext () > { > + /* When gettext support was first added (in 1.8.0), it provided feature > + `i18n'. We keep this as is although the name is a bit misleading > + now. */ > scm_add_feature ("i18n"); OK, but how about (i) adding a "gettext" feature too, (ii) adding a NEWS item to say that the "i18n" feature is deprecated and will be removed in a future release, and that people should check "gettext" instead. > +(dynamic-call "scm_init_i18n" > + (dynamic-link "libguile-i18n-v0")) You should use (load-extension ...) here instead. Then if someone wants to link the i18n lib statically, they can. (Note that I haven't looked in detail at the C code yet; I might do that if I get time in the next few days.) Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-25 18:33 ` Neil Jerram @ 2006-10-26 8:39 ` Ludovic Courtès 0 siblings, 0 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-10-26 8:39 UTC (permalink / raw) Cc: Guile-Devel Hi, Neil Jerram <neil@ossau.uklinux.net> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: >> >> @c Local Variables: >> @c TeX-master: "guile.texi" >> +@c ispell-local-dictionary: "american" > > Hmmm :-) (I'm British.) I guess Guile is an FSF project, and the FSF > is US, though, so OK. :-) OTOH, Guile does not target only US users---if it were, we wouldn't be talking about i18n in the first place. ;-) >> -void >> -scm_init_i18n () >> +void >> +scm_init_gettext () >> { >> + /* When gettext support was first added (in 1.8.0), it provided feature >> + `i18n'. We keep this as is although the name is a bit misleading >> + now. */ >> scm_add_feature ("i18n"); > > OK, but how about (i) adding a "gettext" feature too, (ii) adding a > NEWS item to say that the "i18n" feature is deprecated and will be > removed in a future release, and that people should check "gettext" > instead. I was considering the inclusion of this patch in 1.8. Thus, I initially thought that within the 1.8 branch we shouldn't change feature names _at all_, so we would keep using `i18n' for Gettext, and `ice-9-i18n' for the other. Now, I agree that we should change those names in HEAD. But should we also change them eventually in, say, 1.8.3? >> +(dynamic-call "scm_init_i18n" >> + (dynamic-link "libguile-i18n-v0")) > > You should use (load-extension ...) here instead. Then if someone > wants to link the i18n lib statically, they can. Ok, I'll do it. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-22 18:33 ` Ludovic Courtès 2006-10-23 2:01 ` Rob Browning 2006-10-25 18:33 ` Neil Jerram @ 2006-11-29 23:08 ` Kevin Ryde 2006-11-30 15:19 ` Ludovic Courtès ` (2 more replies) 2006-12-12 19:05 ` Kevin Ryde ` (2 subsequent siblings) 5 siblings, 3 replies; 46+ messages in thread From: Kevin Ryde @ 2006-11-29 23:08 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > I have come up with an `(ice-9 i18n)' module that contains > locale-dependent text collation functions and also character case > mapping and functions to read numbers. There would be a lot more things > to add, like `strfmon ()', but I think that's a good start. I would worry that r6rs may address these things too, leaving guile-specifics as, well, a dead-end. Though I can see this stuff is of use now. Myself I've been using a couple of bits from from localeconv and nl_langinfo. Some way to get at that would be a good addition (though hopefully in a cleaner way than the C level). > [0] http://sources.redhat.com/ml/libc-alpha/2006-09/msg00033.html You could stick that link and perhaps the tllocale.ps.gz one in i18n.c for reference, since it's not in the glibc manual. > +@node The ice-9 i18n Module See if you can think of a better section name. > +@deffn {Scheme Procedure} make-locale category_mask locale_name [base_locale] > ... > +A @code{system-error} exception (@pxref{Handling Errors}) is raised by > +@code{make-locale} when @var{locale_name} does not match any of the > +locales compiled on the system. This bit could be moved to earlier in the description. And perhaps something non-committal like "locale_name must be known to the system". > +@deffn {Scheme Procedure} string-locale<? s1 s2 [locale] > +@deffn {Scheme Procedure} string-locale>? s1 s2 [locale] > +@deffn {Scheme Procedure} string-locale-ci<? s1 s2 [locale] > +@deffn {Scheme Procedure} string-locale-ci>? s1 s2 [locale] > +@deffn {Scheme Procedure} string-locale-ci=? s1 s2 [locale] These could be described in one block I think, to avoid five very similar descriptions. Likewise the char ones. > +... Note that SRFI-13 provides procedures that > +look similar (@pxref{Alphabetic Case Mapping}). However, the SRFI-13 > +procedures are locale-independent. That's the intention of the srfi I guess, but it's not true currently is it? Don't they use toupper() and therefore get whatever nonsense the current setlocale() gives. Perhaps better leave the description of srfi-13 to that section. > +@deffn {Scheme Procedure} string-locale-upcase str [locale] > +@deffn {Scheme Procedure} string-locale-downcase str [locale] Do you need a caveat about multibyte characters there, for now? Like "Note that in the current implementation Guile has no notion of multibyte characters and in a multibyte locale characters may not be converted correctly." > +@deffn {Scheme Procedure} locale-string->integer str [base [locale]] > +@deffn {Scheme Procedure} locale-string->inexact str [locale] I think you should cross-reference strtol and strtod here, since their parsing is rather idiosyncratic. I'd even be a bit tempted to name them strtol and strtod in guile, to make it clear they're only one possible way of parsing. Except those names aren't very nice ... > +... Return two values: Consider @pxref{Multiple Values}, since multi-values are (thankfully) fairly rare. > @c Local Variables: > @c TeX-master: "guile.texi" > +@c ispell-local-dictionary: "american" Best leave that out please, it'll only annoy those of us who don't have that dictionary installed. > +Note that @code{setlocale} affects locale settings for the whole > +process. For a safer, thread-safe and reentrant alternative, Go easy on the advertising! :) > - scmconfig.h.top gettext.h > + scmconfig.h.top libgettext.h I don't think that's good. Best leave gettext.h the gettext one, and use another name for guile. Gettext got there first, and it doesn't really matter which guile header has which prototypes. > +/* This mutex is used to serialize invocations of `setlocale ()' on non-GNU > + systems (i.e., systems where a reentrant locale API is not available). > + See `i18n.c' for details. */ > +scm_i_pthread_mutex_t scm_i_locale_mutex; There's an scm_i_misc_mutex for use when protection is (or should be) rarely needed. > +++ mod/libguile/i18n.c > + > +#ifndef USE_GNU_LOCALE_API > +# include "libguile/posix.h" /* for `scm_i_locale_mutex' */ > +#endif No need to conditionalize that, it's ok if it's only used sometimes, it does no harm. > +/* Provide the locale category masks as found in glibc (copied from > + <locale.h> as found in glibc 2.3.6). This must be kept in sync with > + `locale-categories.h'. */ > +# define LC_CTYPE_MASK (1 << LC_CTYPE) > +# define LC_COLLATE_MASK (1 << LC_COLLATE) > +# define LC_MESSAGES_MASK (1 << LC_MESSAGES) > +# define LC_MONETARY_MASK (1 << LC_MONETARY) > +# define LC_NUMERIC_MASK (1 << LC_NUMERIC) > +# define LC_TIME_MASK (1 << LC_TIME) I think you should put some privately selected bits there, not depend on LC_CTYPE etc being in range 0 to 31. > +/* Alias for glibc's locale type. */ > +typedef locale_t scm_t_locale; I suppose the emulation could provide locale_t. Might make it hard to exercise on an actual gnu system. A #define locale_t would likely be ok. > +SCM_DEFINE (scm_locale_p, "locale?", 1, 0, 0, > ... > + if (SCM_SMOB_PREDICATE (scm_tc16_locale_smob_type, obj)) > + return SCM_BOOL_T; > + return SCM_BOOL_F; scm_from_bool perhaps. > +#ifdef USE_GNU_LOCALE_API > + freelocale ((locale_t)c_locale); > +#else > + c_locale->base_locale = SCM_UNDEFINED; > + free (c_locale->locale_name); > + scm_gc_free (c_locale, sizeof (* c_locale), "locale"); > +#endif A possibility there, and with other funcs, would be to implement a compatible freelocale(), instead of sticking conditionals in each usage. > +#ifdef USE_GNU_LOCALE_API > + > + c_locale = newlocale (c_category_mask, c_locale_name, c_base_locale); > + if (!c_locale) > + locale = SCM_BOOL_F; Your docs call for an exception on unknown locale don't they? And should you tell the gc something about the size of a locale_t, and perhaps extra for its underlying data? To approximate memory used, for the gc triggers. > +void > +scm_init_i18n () > +{ > + scm_add_feature ("ice-9-i18n"); Is there any point adding a feature after the module is loaded? :) I expect a better name would be possible too. > +(define (under-french-locale-or-unresolved thunk) > + ;; On non-GNU systems, an exception may be raised only when the locale is > + ;; actually used rather than at `make-locale'-time. Thus, we must guard > + ;; against both. > + (if %french-locale > + (catch 'system-error thunk > + (lambda (key . args) > + (throw 'unresolved))) > + (throw 'unresolved))) Do you mean 'unsupported rather than 'unresolved, when fr_FR isn't available from the system? > +(with-test-prefix "number parsing" Some french number parsing too? Just to show there's a point to locale dependent parsing :). _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-29 23:08 ` Kevin Ryde @ 2006-11-30 15:19 ` Ludovic Courtès 2006-12-02 21:56 ` Kevin Ryde 2006-12-05 0:38 ` Kevin Ryde 2006-12-02 22:02 ` Kevin Ryde 2006-12-10 12:30 ` Ludovic Courtès 2 siblings, 2 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-11-30 15:19 UTC (permalink / raw) Hi, Kevin Ryde <user42@zip.com.au> writes: > I would worry that r6rs may address these things too, leaving > guile-specifics as, well, a dead-end. Though I can see this stuff is > of use now. Don't worry, R5.91RS doesn't deal with locales and text collation [0], and if it did, we'd just have to provide a wrapper for our API. MzScheme has had a similar API for some time also [1]. > Myself I've been using a couple of bits from from localeconv and > nl_langinfo. Some way to get at that would be a good addition (though > hopefully in a cleaner way than the C level). I've written a wrapper for `nl_langinfo ()' as part of the `i18n' module (it is necessary to internationalize SRFI-19 for instance). This also required the implementation of `scm_from_string ()', a generalized version of `scm_from_locale_string ()' that uses `iconv ()'. I'll write about this later and try to address the other issues you raised at the same time. Thanks, Ludovic. [0] http://lists.gnu.org/archive/html/guile-devel/2006-09/msg00052.html [1] http://download.plt-scheme.org/chronology/mzmr200alpha14.html _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-30 15:19 ` Ludovic Courtès @ 2006-12-02 21:56 ` Kevin Ryde 2006-12-04 9:01 ` Ludovic Courtès 2006-12-05 0:38 ` Kevin Ryde 1 sibling, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-12-02 21:56 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > I've written a wrapper for `nl_langinfo ()' as part of the `i18n' module > (it is necessary to internationalize SRFI-19 for instance). I think the existing strftime is enough, it's just nobody has got around to using it. The only extra would be the decimal point for ~f. If you're interested in srfi-19 then fixing the date conversion would be the best thing to do (dates prior to 1582 use gregorian leap years, where it should be julian; it gets for instance a wrong start point for the julian day numbers). _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-02 21:56 ` Kevin Ryde @ 2006-12-04 9:01 ` Ludovic Courtès 2006-12-05 0:20 ` Kevin Ryde 0 siblings, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-12-04 9:01 UTC (permalink / raw) Hi, Kevin Ryde <user42@zip.com.au> writes: > I think the existing strftime is enough, it's just nobody has got > around to using it. The only extra would be the decimal point for ~f. I suspect that this would be suboptimal. SRFI-19 has its own template format for `date->string', and internally it uses primitives equivalent to `nl_langinfo (DAY_1)' and the likes (the `priv:locale' functions). > If you're interested in srfi-19 then fixing the date conversion would > be the best thing to do (dates prior to 1582 use gregorian leap years, > where it should be julian; it gets for instance a wrong start point > for the julian day numbers). I don't clearly understand. Could you provide more details for the novice (perhaps in another thread)? :-) Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-04 9:01 ` Ludovic Courtès @ 2006-12-05 0:20 ` Kevin Ryde 2006-12-05 18:42 ` Carl Witty 0 siblings, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-12-05 0:20 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > I suspect that this would be suboptimal. SRFI-19 has its own template > format for `date->string', and internally it uses primitives equivalent > to `nl_langinfo (DAY_1)' and the likes (the `priv:locale' functions). No need to worry about the existing internals. strftime may be necessary (at some level) on systems with only localeconv (ie. not nl_langinfo), though I don't know how common that would be or if it's worth taking trouble over. > I don't clearly understand. Could you provide more details for the > novice (perhaps in another thread)? :-) The note in the manual: *Caution*: The current code in this module incorrectly extends the Gregorian calendar leap year rule back prior to the introduction of those reforms in 1582 (or the appropriate year in various countries). The Julian calendar was used prior to 1582, and there were 10 days skipped for the reform, but the code doesn't implement that. So for instance the year 1500 should be a leap year, but isn't in the current code. (If I've got that right off the top of my head ... :-) _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-05 0:20 ` Kevin Ryde @ 2006-12-05 18:42 ` Carl Witty 2006-12-05 20:41 ` Kevin Ryde 0 siblings, 1 reply; 46+ messages in thread From: Carl Witty @ 2006-12-05 18:42 UTC (permalink / raw) Cc: Guile-Devel On Tue, 2006-12-05 at 11:20 +1100, Kevin Ryde wrote: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > I don't clearly understand. Could you provide more details for the > > novice (perhaps in another thread)? :-) > > The note in the manual: > > *Caution*: The current code in this module incorrectly extends > the Gregorian calendar leap year rule back prior to the > introduction of those reforms in 1582 (or the appropriate year > in various countries). The Julian calendar was used prior to > 1582, and there were 10 days skipped for the reform, but the > code doesn't implement that. > > So for instance the year 1500 should be a leap year, but isn't in the > current code. (If I've got that right off the top of my head ... :-) If I understand correctly, this would make date->julian-day (for instance) convert from Julian calendar dates before 1582 and Gregorian calendar dates after 1582. This is cute, but I don't think it's particularly useful; the problem is that the Julian to Gregorian switch lasted for hundreds of years around the world (and, indeed, some churches still use the Julian calendar to determine religious dates), so you can't tell if a date is Julian or Gregorian just by looking at the year. I would propose leaving the code the way it is now, and changing the note to something like "Note: Dates in this module use the proleptic Gregorian calendar, which means that it extends the Gregorian calendar leap year rule back prior to the introduction of these reforms in 1582." (See http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar for more information on the proleptic Gregorian calendar.) If people need to use Julian dates, then there should be a separate julian-date type with separate converters. Carl Witty _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-05 18:42 ` Carl Witty @ 2006-12-05 20:41 ` Kevin Ryde 2006-12-05 22:29 ` Carl Witty 0 siblings, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-12-05 20:41 UTC (permalink / raw) Cc: Guile-Devel Carl Witty <cwitty@newtonlabs.com> writes: > > If I understand correctly, this would make date->julian-day (for > instance) convert from Julian calendar dates before 1582 and Gregorian > calendar dates after 1582. Yes. > This is cute, but I don't think it's particularly useful; Apart from being what people actually used then! > the problem is that the Julian to Gregorian switch > lasted for hundreds of years around the world (and, indeed, some > churches still use the Julian calendar to determine religious dates), so > you can't tell if a date is Julian or Gregorian just by looking at the > year. Yes, the switch happened at different times, but if you're calling it gregorian then it makes some sense to go with the date pope gregory signed off on :). It could get some localization perhaps, though that sounds like hard work. I think the gnu "cal" program does that. > I would propose leaving the code the way it is now, and changing > the note to something like "Note: Dates in this module use the proleptic > Gregorian calendar, If the srfi author wanted to clarify that then it'd be ok, otherwise surely a calendar with at least some sort of historical basis is more use. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-05 20:41 ` Kevin Ryde @ 2006-12-05 22:29 ` Carl Witty 0 siblings, 0 replies; 46+ messages in thread From: Carl Witty @ 2006-12-05 22:29 UTC (permalink / raw) Cc: Guile-Devel On Wed, 2006-12-06 at 07:41 +1100, Kevin Ryde wrote: > Carl Witty <cwitty@newtonlabs.com> writes: > > > > If I understand correctly, this would make date->julian-day (for > > instance) convert from Julian calendar dates before 1582 and Gregorian > > calendar dates after 1582. > > Yes. > > > This is cute, but I don't think it's particularly useful; > > Apart from being what people actually used then! > > > the problem is that the Julian to Gregorian switch > > lasted for hundreds of years around the world (and, indeed, some > > churches still use the Julian calendar to determine religious dates), so > > you can't tell if a date is Julian or Gregorian just by looking at the > > year. > > Yes, the switch happened at different times, but if you're calling it > gregorian then it makes some sense to go with the date pope gregory > signed off on :). It could get some localization perhaps, though that > sounds like hard work. I think the gnu "cal" program does that. I believe that virtually any program that needs to do date computations on historical dates will need more support than SRFI-19 provides, no matter what meaning we assign to "date"s with years before 1582. If you consider the small set of Guile users who need to do date computation for historical dates, and the even smaller set for which "before 1582 is Julian, after 1582 is Gregorian" is exactly the date semantics they want, I think it is quite possible that this smaller set is empty: that nobody would ever correctly use the SRFI-19 "date" type for historical dates. (My totally-made-up estimate is that the likelihood of wanting a split in October 1582 is about the same as the likelihood of wanting the proleptic Gregorian calendar, which is at least used for ISO 8601; and that both of these are far more likely than wanting a split which is automatically computed based on the locale of the user running the program.) If it is indeed true that nobody would ever correctly use a split-at-1582 date type, then the decision should be made on the basis of the difficulty of implementing, testing, and documenting. It seems like implementing and testing the proleptic Gregorian calendar is far easier than the split-at-1582 calendar, and the difficulty of documenting either is about even. > > I would propose leaving the code the way it is now, and changing > > the note to something like "Note: Dates in this module use the proleptic > > Gregorian calendar, > > If the srfi author wanted to clarify that then it'd be ok, otherwise > surely a calendar with at least some sort of historical basis is more > use. I note that the SRFI does say "A date is a representation of a point in time in the Gregorian calendar..." Carl Witty _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-30 15:19 ` Ludovic Courtès 2006-12-02 21:56 ` Kevin Ryde @ 2006-12-05 0:38 ` Kevin Ryde 1 sibling, 0 replies; 46+ messages in thread From: Kevin Ryde @ 2006-12-05 0:38 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 833 bytes --] ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > I've written a wrapper for `nl_langinfo ()' as part of the `i18n' module What do other schemes or lisps do? I had an idea one of the srfis had some bits but they weren't great. I started a localeconv bit (below) using a vector for all info, though I'm now inclined to think a function with a symbol arg would be friendlier than a big object return. (langinfo 'thousands-sep) => "," Or "localeinfo" or "localeconv" or something. In my charting program I made a separate function for each of the few bits I wanted, (locale-decimal-point) => "." (locale-d-fmt) => "%d/%m/%y" One cute thing about that is that the user can override to personal preferences by `set!'ing in a new function, like having "%b" for the month in the date format. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: localeconv.c --] [-- Type: text/x-csrc, Size: 2416 bytes --] #define _GNU_SOURCE /* ask glibc for C99 lconv fields */ #include <locale.h> SCM_DEFINE (scm_localeconv, "localeconv", 0, 0, 0, (), "Return an ``lconv'' object representing current locale specific\n" "information.") #define FUNC_NAME s_scm_localtime { SCM result; const struct lconv *l; #define LCONV_STR(idx, field) \ SCM_VECTOR_SET (result, idx, scm_makfrom0str (l->field)) #define LCONV_INT(idx, field) \ SCM_VECTOR_SET (result, idx, SCM_MAKINUM (l->field)) /* group array ends with either 0 or CHAR_MAX */ #define LCONV_GRP(idx, field) \ do { \ SCM vec; \ int n, i; \ for (i = 0; l->field[i] != 0 && l->field[i] != CHAR_MAX; i++) \ ; \ n = i + 1; /* number of elements */ \ vec = scm_c_make_vector (n, SCM_BOOL_F); \ for (i = 0; i < n; i++) \ SCM_VECTOR_SET (result, idx, SCM_MAKINUM (l->field[i])); \ SCM_VECTOR_SET (result, idx, vec); \ } while (0) result = scm_c_make_vector (11, SCM_BOOL_F); SCM_DEFER_INTS; LCONV_STR ( 0, decimal_point); LCONV_STR ( 1, thousands_sep); LCONV_GRP ( 2, grouping); LCONV_STR ( 3, int_curr_symbol); LCONV_STR ( 4, currency_symbol); LCONV_STR ( 5, mon_decimal_point); LCONV_STR ( 6, mon_thousands_sep); LCONV_GRP ( 7, mon_grouping); LCONV_STR ( 8, positive_sign); LCONV_STR ( 9, negative_sign); LCONV_INT (10, int_frac_digits); LCONV_INT (11, frac_digits); LCONV_INT (12, p_cs_precedes); LCONV_INT (13, p_sep_by_space); LCONV_INT (14, n_cs_precedes); LCONV_INT (15, n_sep_by_space); LCONV_INT (16, p_sign_posn); LCONV_INT (17, n_sign_posn); /* C99 extras, apparently */ #if HAVE_LCONV_INT_P_CS_PRECEDES LCONV_INT (18, int_p_cs_precedes); LCONV_INT (19, int_p_sep_by_space); LCONV_INT (20, int_n_cs_precedes); LCONV_INT (21, int_n_sep_by_space); LCONV_INT (22, int_p_sign_posn); LCONV_INT (23, int_n_sign_posn); #endif return result; } [-- Attachment #3: Type: text/plain, Size: 143 bytes --] _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-29 23:08 ` Kevin Ryde 2006-11-30 15:19 ` Ludovic Courtès @ 2006-12-02 22:02 ` Kevin Ryde 2006-12-10 12:30 ` Ludovic Courtès 2 siblings, 0 replies; 46+ messages in thread From: Kevin Ryde @ 2006-12-02 22:02 UTC (permalink / raw) I wrote: > >> +@deffn {Scheme Procedure} locale-string->integer str [base [locale]] >> +@deffn {Scheme Procedure} locale-string->inexact str [locale] > > I think you should cross-reference strtol and strtod here, since their > parsing is rather idiosyncratic. I'd even be a bit tempted to name > them strtol and strtod in guile, to make it clear they're only one > possible way of parsing. Except those names aren't very nice ... I'm now sure these should be called strtol and probably strtod, because they're actually pretty awful functions. The syntax they recognise is C style, and the error return for overflow is not too friendly. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-11-29 23:08 ` Kevin Ryde 2006-11-30 15:19 ` Ludovic Courtès 2006-12-02 22:02 ` Kevin Ryde @ 2006-12-10 12:30 ` Ludovic Courtès 2006-12-11 22:32 ` Kevin Ryde 2 siblings, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-12-10 12:30 UTC (permalink / raw) Hi, Just a few notes about your remarks regarding `(ice-9 i18n)'. A patch will follow soon. Kevin Ryde <user42@zip.com.au> writes: >> +@node The ice-9 i18n Module > > See if you can think of a better section name. Actually, since we're not going to include this module in 1.8, I think I'd be in favor of moving the `gettext'-related functions in `(ice-9 i18n)'. Then the doc would have to be rearranged accordingly. >> +@deffn {Scheme Procedure} string-locale<? s1 s2 [locale] >> +@deffn {Scheme Procedure} string-locale>? s1 s2 [locale] >> +@deffn {Scheme Procedure} string-locale-ci<? s1 s2 [locale] >> +@deffn {Scheme Procedure} string-locale-ci>? s1 s2 [locale] >> +@deffn {Scheme Procedure} string-locale-ci=? s1 s2 [locale] > > These could be described in one block I think, to avoid five very > similar descriptions. Likewise the char ones. Yes, done. >> +... Note that SRFI-13 provides procedures that >> +look similar (@pxref{Alphabetic Case Mapping}). However, the SRFI-13 >> +procedures are locale-independent. > > That's the intention of the srfi I guess, but it's not true currently > is it? Don't they use toupper() and therefore get whatever nonsense > the current setlocale() gives. Perhaps better leave the description > of srfi-13 to that section. Perhaps, but this is undocumented behavior. :-) > Do you need a caveat about multibyte characters there, for now? Like > "Note that in the current implementation Guile has no notion of > multibyte characters and in a multibyte locale characters may not be > converted correctly." Yes. >> +@deffn {Scheme Procedure} locale-string->integer str [base [locale]] >> +@deffn {Scheme Procedure} locale-string->inexact str [locale] > > I think you should cross-reference strtol and strtod here, since their > parsing is rather idiosyncratic. I'd even be a bit tempted to name > them strtol and strtod in guile, to make it clear they're only one > possible way of parsing. Except those names aren't very nice ... I added a cross-ref to glibc's `strto{dl}', but I'm not willing to change the names to the C library names (I'm not sure that's what you were suggesting though). >> +... Return two values: > > Consider @pxref{Multiple Values}, since multi-values are (thankfully) > fairly rare. Yes, done. >> - scmconfig.h.top gettext.h >> + scmconfig.h.top libgettext.h > > I don't think that's good. Best leave gettext.h the gettext one, and > use another name for guile. Gettext got there first, and it doesn't > really matter which guile header has which prototypes. The former `i18n.c' (which contained only `gettext'-related code) was renamed to `gettext.c' which seems more appropriate. Thus, for consistency, the corresponding header file had to be renamed from `i18n.h' to `gettext.h'. Since `gettext.h' was already used for the one coming from Gettext, it had to be renamed. `libgettext.h' doesn't seem such a bad name to me. >> +/* This mutex is used to serialize invocations of `setlocale ()' on non-GNU >> + systems (i.e., systems where a reentrant locale API is not available). >> + See `i18n.c' for details. */ >> +scm_i_pthread_mutex_t scm_i_locale_mutex; > > There's an scm_i_misc_mutex for use when protection is (or should be) > rarely needed. It seems more robust to use a dedicated mutex. >> +/* Provide the locale category masks as found in glibc (copied from >> + <locale.h> as found in glibc 2.3.6). This must be kept in sync with >> + `locale-categories.h'. */ >> +# define LC_CTYPE_MASK (1 << LC_CTYPE) >> +# define LC_COLLATE_MASK (1 << LC_COLLATE) >> +# define LC_MESSAGES_MASK (1 << LC_MESSAGES) >> +# define LC_MONETARY_MASK (1 << LC_MONETARY) >> +# define LC_NUMERIC_MASK (1 << LC_NUMERIC) >> +# define LC_TIME_MASK (1 << LC_TIME) > > I think you should put some privately selected bits there, not depend > on LC_CTYPE etc being in range 0 to 31. Good point, done. >> +/* Alias for glibc's locale type. */ >> +typedef locale_t scm_t_locale; > > I suppose the emulation could provide locale_t. Might make it hard to > exercise on an actual gnu system. A #define locale_t would likely be > ok. It seems safer to make changes only in the `scm_' name space. As a matter of fact, I just discovered that Darwin now implements the `locale_t' "GNU" API (I suppose that change is quite recent): http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/newlocale.3.html Thus, defining `locale_t', `newlocale', et al. internally would have been a potential source of problems when building on that platform. >> +#ifdef USE_GNU_LOCALE_API >> + freelocale ((locale_t)c_locale); >> +#else >> + c_locale->base_locale = SCM_UNDEFINED; >> + free (c_locale->locale_name); >> + scm_gc_free (c_locale, sizeof (* c_locale), "locale"); >> +#endif > > A possibility there, and with other funcs, would be to implement a > compatible freelocale(), instead of sticking conditionals in each > usage. (See above). >> +#ifdef USE_GNU_LOCALE_API >> + >> + c_locale = newlocale (c_category_mask, c_locale_name, c_base_locale); >> + if (!c_locale) >> + locale = SCM_BOOL_F; > > Your docs call for an exception on unknown locale don't they? Indeed, fixed. > And should you tell the gc something about the size of a locale_t, and > perhaps extra for its underlying data? To approximate memory used, > for the gc triggers. Yes, but `locale_t' is typically a pointer type, and the size of the struct pointed to by `locale_t' could be opaque (although that is currently not the case with glibc). So we could provide a guess for the underlying object size, but maybe we can also just safely ignore it? >> +void >> +scm_init_i18n () >> +{ >> + scm_add_feature ("ice-9-i18n"); > > Is there any point adding a feature after the module is loaded? :) Indeed, removed. :-) >> +(define (under-french-locale-or-unresolved thunk) >> + ;; On non-GNU systems, an exception may be raised only when the locale is >> + ;; actually used rather than at `make-locale'-time. Thus, we must guard >> + ;; against both. >> + (if %french-locale >> + (catch 'system-error thunk >> + (lambda (key . args) >> + (throw 'unresolved))) >> + (throw 'unresolved))) > > Do you mean 'unsupported rather than 'unresolved, when fr_FR isn't > available from the system? I really meant "unresolved", in the sense that the test cannot be run when `fr_FR' isn't available. >> +(with-test-prefix "number parsing" > > Some french number parsing too? Just to show there's a point to > locale dependent parsing :). Done. Thanks for your detailed review! Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-10 12:30 ` Ludovic Courtès @ 2006-12-11 22:32 ` Kevin Ryde 2006-12-12 8:38 ` Ludovic Courtès 0 siblings, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-12-11 22:32 UTC (permalink / raw) Cc: guile-devel ludo@chbouib.org (Ludovic Courtès) writes: > > I'd be in favor of moving the `gettext'-related functions in `(ice-9 > i18n)'. They'll be used by the core to translate various core messages at some stage, that's why they're there. [srfi-13] > Perhaps, but this is undocumented behavior. :-) Keep to a minimum what you say about a function in a separate part of the manual. > strto{dl} The reason those funcs are hardly used is that they're not very good. Traditionally strtol had no overflow checking, and even now c99 doesn't guarantee localized forms for either. Also strtod may or may not have the helpful "p" format, and its rounding isn't guaranteed (only "recommended practice"). There's no particular virtue in the C library. If you want to hook onto it then name functions accordingly, so everyone knows what to expect. If you want better semantics, hopefully more scheme-like, then use names reflecting that betterness. > The former `i18n.c' (which contained only `gettext'-related code) was > renamed to `gettext.c' which seems more appropriate. Please try to resist the temptation to make non-changes. > It seems more robust to use a dedicated mutex. If you say you're concerned about speed of startup and size of modules :-), then you don't want to create a new mutex. The common one is specifically there for miscellaneous uses. > I really meant "unresolved", in the sense that the test cannot be run > when `fr_FR' isn't available. "unresolved" is for bugs not yet addressed, or long-standing misfeatures not easily fixed. I'm pretty sure "unsupported" is intended for things not available on account of the system environment. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-11 22:32 ` Kevin Ryde @ 2006-12-12 8:38 ` Ludovic Courtès 2006-12-12 20:04 ` Kevin Ryde 2006-12-15 20:52 ` Kevin Ryde 0 siblings, 2 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-12-12 8:38 UTC (permalink / raw) Hi, Kevin Ryde <user42@zip.com.au> writes: >> strto{dl} > > The reason those funcs are hardly used is that they're not very good. > Traditionally strtol had no overflow checking, and even now c99 > doesn't guarantee localized forms for either. Also strtod may or may > not have the helpful "p" format, and its rounding isn't guaranteed > (only "recommended practice"). Ok, I wasn't aware of this. > There's no particular virtue in the C library. If you want to hook > onto it then name functions accordingly, so everyone knows what to > expect. If you want better semantics, hopefully more scheme-like, > then use names reflecting that betterness. That makes sense, but OTOH, we want to avoid silly names I guess. ;-) So, do you think we should rename them to `strto{d,l}' or documenting this dependence is enough? >> The former `i18n.c' (which contained only `gettext'-related code) was >> renamed to `gettext.c' which seems more appropriate. > > Please try to resist the temptation to make non-changes. I couldn't think of any other option that would retain consistency. > If you say you're concerned about speed of startup and size of > modules :-), then you don't want to create a new mutex. The common one > is specifically there for miscellaneous uses. The mutex is statically initialized, how can it impact startup time? More importantly: what's the semantics of a "misc" mutex? Suppose function `foo' invokes `bar', which in turn invokes `string-locale<?'. What if both `foo' and `string-locale<?' turn out to lock the "misc" mutex upon entry? >> I really meant "unresolved", in the sense that the test cannot be run >> when `fr_FR' isn't available. > > "unresolved" is for bugs not yet addressed, or long-standing > misfeatures not easily fixed. I'm pretty sure "unsupported" is > intended for things not available on account of the system > environment. Hmm, I thought `unresolved' was for cases where a test cannot be run for some reason. See, e.g., `guardians.test', `socket.test'. OTOH, `unsupported' seems to be used when a feature cannot be tested because it wasn't compiled in (e.g., `alist.test'). Well, there's admittedly not a huge difference. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-12 8:38 ` Ludovic Courtès @ 2006-12-12 20:04 ` Kevin Ryde 2006-12-13 9:41 ` Ludovic Courtès 2006-12-31 17:10 ` Neil Jerram 2006-12-15 20:52 ` Kevin Ryde 1 sibling, 2 replies; 46+ messages in thread From: Kevin Ryde @ 2006-12-12 20:04 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > So, do you think we should rename them to `strto{d,l}' or documenting > this dependence is enough? Number parsing on the whole always seems very application-specific to me. I don't think I've ever seen a style that could recommended whole-heartedly for all user input :-(. I'd think about something modest like a string->number that stripped thousands seps and transformed the decimal point (if necessary). I think that'd find a use. > Hmm, I thought `unresolved' was for cases where a test cannot be run for > some reason. See, e.g., `guardians.test', Not sure about those, were they actually unresolved issues for a time? > `socket.test' Hang on, that's your work isn't it! :) > Well, there's admittedly not a huge difference. Yes, though hopefully the difference is that "unsupported" bits can be safely ignored, assuming you know those features are not supposed to be available. But the author of this stuff must be lurking here ... _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-12 20:04 ` Kevin Ryde @ 2006-12-13 9:41 ` Ludovic Courtès 2006-12-31 17:10 ` Neil Jerram 1 sibling, 0 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-12-13 9:41 UTC (permalink / raw) Kevin Ryde <user42@zip.com.au> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: >> >> So, do you think we should rename them to `strto{d,l}' or documenting >> this dependence is enough? > > Number parsing on the whole always seems very application-specific to > me. I don't think I've ever seen a style that could recommended > whole-heartedly for all user input :-(. Right. > I'd think about something modest like a string->number that stripped > thousands seps and transformed the decimal point (if necessary). I > think that'd find a use. Sure. >> Hmm, I thought `unresolved' was for cases where a test cannot be run for >> some reason. See, e.g., `guardians.test', > > Not sure about those, were they actually unresolved issues for a time? The idea (I think) is that, for instance, when SEEN-G3-GARBAGE is false, you can't decide if that's because the guardian code is actually buggy or if that's because the GC is somehow rightfully retaining G3. IOW, you can't decide whether the test case passes or not, so you throw `unresolved'. >> `socket.test' > > Hang on, that's your work isn't it! :) Oh, right. :-) Thanks, Ludo'. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-12 20:04 ` Kevin Ryde 2006-12-13 9:41 ` Ludovic Courtès @ 2006-12-31 17:10 ` Neil Jerram 1 sibling, 0 replies; 46+ messages in thread From: Neil Jerram @ 2006-12-31 17:10 UTC (permalink / raw) Kevin Ryde <user42@zip.com.au> writes: > Yes, though hopefully the difference is that "unsupported" bits can be > safely ignored, assuming you know those features are not supposed to > be available. But the author of this stuff must be lurking here ... That would be Jim Blandy. He might be lurking, but I think it's unlikely, as he hasn't posted anything for ages. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-12 8:38 ` Ludovic Courtès 2006-12-12 20:04 ` Kevin Ryde @ 2006-12-15 20:52 ` Kevin Ryde 1 sibling, 0 replies; 46+ messages in thread From: Kevin Ryde @ 2006-12-15 20:52 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > mutex If you want to think about mutexes, the timezone swapping in stime.c could stand some attention. When changing the "environ" global variable it uses the old SCM_CRITICAL_SECTION_START business, which is a secret mutex. It, and probably your locale bits, should expose something so C code (including wrappers around external libraries) can lock down afflicted bits when necessary. There's no need for a separate mutex for each thing. When an operation like time conversion or locale query is fast then no important parallelism is lost by sharing. And if you've got multiple mutexes that might be acquired all at once then you have to think about the sequence to do that in, otherwise there's risk of a deadly embrace. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-22 18:33 ` Ludovic Courtès ` (2 preceding siblings ...) 2006-11-29 23:08 ` Kevin Ryde @ 2006-12-12 19:05 ` Kevin Ryde 2006-12-13 9:14 ` Ludovic Courtès 2006-12-12 19:16 ` Kevin Ryde 2006-12-12 21:37 ` Kevin Ryde 5 siblings, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-12-12 19:05 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > +++ mod/libguile/posix.c >... > +#ifndef USE_GNU_LOCALE_API > + scm_i_pthread_mutex_lock (&scm_i_locale_mutex); > +#endif > rv = setlocale (scm_i_to_lc_category (category, 1), clocale); > +#ifndef USE_GNU_LOCALE_API > + scm_i_pthread_mutex_unlock (&scm_i_locale_mutex); > +#endif Looks like a mutex leak here if scm_i_to_lc_category throws an error. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-12 19:05 ` Kevin Ryde @ 2006-12-13 9:14 ` Ludovic Courtès 0 siblings, 0 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-12-13 9:14 UTC (permalink / raw) Hi, Kevin Ryde <user42@zip.com.au> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: >> >> +++ mod/libguile/posix.c >>... >> +#ifndef USE_GNU_LOCALE_API >> + scm_i_pthread_mutex_lock (&scm_i_locale_mutex); >> +#endif >> rv = setlocale (scm_i_to_lc_category (category, 1), clocale); >> +#ifndef USE_GNU_LOCALE_API >> + scm_i_pthread_mutex_unlock (&scm_i_locale_mutex); >> +#endif > > Looks like a mutex leak here if scm_i_to_lc_category throws an error. Indeed! I'll fix it in a while. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-22 18:33 ` Ludovic Courtès ` (3 preceding siblings ...) 2006-12-12 19:05 ` Kevin Ryde @ 2006-12-12 19:16 ` Kevin Ryde 2006-12-13 9:20 ` Ludovic Courtès 2006-12-12 21:37 ` Kevin Ryde 5 siblings, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-12-12 19:16 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > +@defvar LC_ALL_MASK > +This represents all the locale categories supported by the system. How about having make-locale take the existing LC_MESSAGES etc. I'm thinking either a single LC value, or a list of them for multiple categories. I'm pretty sure there's no need for a second parallel set of values, and that it's a good chance of being confusing. Someone's bound to write (make-locale LC_ALL ... and wonder why it doesn't work (and doesn't give an error either). _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-12 19:16 ` Kevin Ryde @ 2006-12-13 9:20 ` Ludovic Courtès 0 siblings, 0 replies; 46+ messages in thread From: Ludovic Courtès @ 2006-12-13 9:20 UTC (permalink / raw) Hi, Kevin Ryde <user42@zip.com.au> writes: > How about having make-locale take the existing LC_MESSAGES etc. I'm > thinking either a single LC value, or a list of them for multiple > categories. I considered this option at some point but then thought lists were a too high-level construct. ;-) Seriously, one could argue that lists are more "expensive" (to store and process), but that's not big deal anyway since the list is likely to contain only a couple of values. So I'll make this change. Thanks! Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-10-22 18:33 ` Ludovic Courtès ` (4 preceding siblings ...) 2006-12-12 19:16 ` Kevin Ryde @ 2006-12-12 21:37 ` Kevin Ryde 2006-12-13 9:28 ` Ludovic Courtès 5 siblings, 1 reply; 46+ messages in thread From: Kevin Ryde @ 2006-12-12 21:37 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > +/* Throw an exception corresponding to error ERR. */ > +static void inline > +scm_locale_error (const char *func_name, int err) > +{ > + SCM s_err; > + > + s_err = scm_from_int (err); > + scm_error (scm_system_error_key, func_name, > + "Failed to install locale", > + scm_cons (scm_strerror (s_err), SCM_EOL), > + scm_cons (s_err, SCM_EOL)); > +} This doesn't display, <unnamed port>:3:1: In procedure string-locale<? in expression (string-locale<? "x" "y" ...): <unnamed port>:3:1: Failed to install locale Exception during displaying of error: misc-error ABORT: (system-error) It'd be good if it was a standard SCM_SYSERROR and was detected on creating a locale. Incidentally, in the fallback code there seems to be something fishy after a failed install. If you try to use the offending locale object a second time it succeeds. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-12 21:37 ` Kevin Ryde @ 2006-12-13 9:28 ` Ludovic Courtès 2006-12-13 20:10 ` Kevin Ryde 0 siblings, 1 reply; 46+ messages in thread From: Ludovic Courtès @ 2006-12-13 9:28 UTC (permalink / raw) Kevin Ryde <user42@zip.com.au> writes: > ludovic.courtes@laas.fr (Ludovic Courtès) writes: >> >> +/* Throw an exception corresponding to error ERR. */ >> +static void inline >> +scm_locale_error (const char *func_name, int err) >> +{ >> + SCM s_err; >> + >> + s_err = scm_from_int (err); >> + scm_error (scm_system_error_key, func_name, >> + "Failed to install locale", >> + scm_cons (scm_strerror (s_err), SCM_EOL), >> + scm_cons (s_err, SCM_EOL)); >> +} > > This doesn't display, > > <unnamed port>:3:1: In procedure string-locale<? in expression (string-locale<? > "x" "y" ...): > <unnamed port>:3:1: Failed to install locale > Exception during displaying of error: misc-error > ABORT: (system-error) That's on a system where `USE_GNU_LOCALE_API' is not defined, right? > It'd be good if it was a standard SCM_SYSERROR and was detected on > creating a locale. It's not an `SCM_SYSERROR' because the error code is provided by variable ERR, not by ERRNO. That said, it could use `SCM_SYSERROR_MSG'. In order to detect locale unavailability upon locale create on non-GNU systems, it would have to try to actually install the locale first. I guess we can do it, although that adds a bit of overhead. > Incidentally, in the fallback code there seems to be something fishy > after a failed install. If you try to use the offending locale object > a second time it succeeds. Hmm, weird. Is the locale in question available on your system? I'll give it a try. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: Text collation 2006-12-13 9:28 ` Ludovic Courtès @ 2006-12-13 20:10 ` Kevin Ryde 0 siblings, 0 replies; 46+ messages in thread From: Kevin Ryde @ 2006-12-13 20:10 UTC (permalink / raw) ludovic.courtes@laas.fr (Ludovic Courtès) writes: > > That's on a system where `USE_GNU_LOCALE_API' is not defined, right? Yes, faked out. > In order to detect locale unavailability upon locale create on non-GNU > systems, it would have to try to actually install the locale first. I > guess we can do it, although that adds a bit of overhead. Worth doing, to make the fallback work like the real thing. > Hmm, weird. Is the locale in question available on your system? No, a bogus name deliberately trying to provoke. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2006-12-31 17:10 UTC | newest] Thread overview: 46+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-09-19 9:23 Text collation Ludovic Courtès 2006-09-19 22:38 ` Kevin Ryde 2006-10-22 18:33 ` Ludovic Courtès 2006-10-23 2:01 ` Rob Browning 2006-10-23 7:56 ` Ludovic Courtès 2006-10-24 8:37 ` Rob Browning 2006-10-25 8:16 ` Ludovic Courtès 2006-10-25 8:46 ` Rob Browning 2006-10-25 18:40 ` Neil Jerram 2006-10-25 19:55 ` Rob Browning 2006-10-26 8:47 ` Ludovic Courtès 2006-11-09 7:44 ` Ludovic Courtès 2006-11-09 17:43 ` Rob Browning 2006-11-10 13:39 ` Ludovic Courtès 2006-11-11 15:17 ` Neil Jerram 2006-11-20 13:24 ` Ludovic Courtès 2006-11-21 22:03 ` Neil Jerram 2006-11-22 13:38 ` Ludovic Courtès 2006-10-25 18:43 ` Neil Jerram 2006-10-25 19:31 ` Rob Browning 2006-10-25 18:33 ` Neil Jerram 2006-10-26 8:39 ` Ludovic Courtès 2006-11-29 23:08 ` Kevin Ryde 2006-11-30 15:19 ` Ludovic Courtès 2006-12-02 21:56 ` Kevin Ryde 2006-12-04 9:01 ` Ludovic Courtès 2006-12-05 0:20 ` Kevin Ryde 2006-12-05 18:42 ` Carl Witty 2006-12-05 20:41 ` Kevin Ryde 2006-12-05 22:29 ` Carl Witty 2006-12-05 0:38 ` Kevin Ryde 2006-12-02 22:02 ` Kevin Ryde 2006-12-10 12:30 ` Ludovic Courtès 2006-12-11 22:32 ` Kevin Ryde 2006-12-12 8:38 ` Ludovic Courtès 2006-12-12 20:04 ` Kevin Ryde 2006-12-13 9:41 ` Ludovic Courtès 2006-12-31 17:10 ` Neil Jerram 2006-12-15 20:52 ` Kevin Ryde 2006-12-12 19:05 ` Kevin Ryde 2006-12-13 9:14 ` Ludovic Courtès 2006-12-12 19:16 ` Kevin Ryde 2006-12-13 9:20 ` Ludovic Courtès 2006-12-12 21:37 ` Kevin Ryde 2006-12-13 9:28 ` Ludovic Courtès 2006-12-13 20:10 ` Kevin Ryde
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).