Re: [RFC] introducing new locale-db implementation (Re: lib/39662: shortcomings in LC_{MONETARY,NUMERIC,TIME,MESSAGES} db format)

["Takehiko NOZAKI" <takehiko.nozaki%gmail.com@localhost>]

hi,

> From the non-developer point of view, any examples of what NetBSD
> end-users / administrators can do to notice or take advantage of the new
> improved LC_MONETARY, LC_NUMERIC, LC_TIME, LC_MESSAGES?

non-developer's point of view, nothing at this time ;-<

i've just worked for the developer's sake:
 - keeping binary compatibility/file versioning issue.
 - endianess issue for the further impletation of wide-character API.

if i dare to say, the locale caching mechanism. if your application
frequently change
locale setting by calling setlocale(3) (and more, locale-db is on NFS
Server etc...).
it may be faster than previous one, but i don't imagine such
application, almost application
only call setlocale(3) at once.

however the main purpose of introducing this locale caching mechanism is
not for performance issue, but for multi-locale implementation.

what is multi-locale?

C++ standard defines multi-locale, but C standard lacks this functions(*1).
    *1) http://stdcxx.apache.org/doc/stdlibug/24-3.html

also our libstdc++'s multi-locale doesn't work like following FreeBSD's PR.
    http://lists.freebsd.org/pipermail/freebsd-i18n/2008-April/000181.html

TOG once consideried to introduce Distributed I18N Framework(*2)
as multi-locale supports, but not accepted widely.
    *2) http://www.opengroup.org/bookstore/catalog/s503.htm

so glibc2 peoples decided to introduce thier own Thread Aware Locale Model(*3)
    *3) http://people.redhat.com/drepper/tllocale.ps.gz

and now GNU libstd++ depends on these functions.
(please grep locale::facet::_S_create_c_locale in libstdc++ directory)

this is already included latest Linux Standard Base(*4).
    *4) 
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/libc.html#AEN3455

and it is more widely accepted, now MacOS X(*5)  and Microsoft
VisualStudio>=2008(*6) have similar APIs.
    *5) 
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html#//apple_ref/doc/man/3/xlocale
    *6) http://msdn.microsoft.com/ja-jp/library/wyzd2bce(VS.80).aspx

so i believe we need introduce it in our libc, i'll work it for 6.0.

here is earily stage of snapshot of my work.
ftp://ftp.netbsd.org/pub/NetBSD/misc/tnozaki/multi-locale-snapshot-20090102.tar.gz

if done, i think it is benefit for non-developer such as:
"this C++ application runs on Linux, but NetBSD doesn't!"


> And for NetBSD developers, what can we do to help build upon these
> improvements?

if you see date(1) outputs strange curious format date in your locale setting,
(i know japanese locale is heavily broken, sigh...)
or strftime(3), stfmon(3) can't parse your localized string, please tell me.

for multi-locale implementation,  Thread Local Storage will great help for me :D
(i don't want touch pthread_t for uselocale(3) implementation).
is there someone work on it?

> And does the chrtbl.8 manual page need to be updated? (It discusses that
> LC_NUMERIC is not fully implemented.)

chrtbl(1) is the zombie from SysV,  it is already obsoleted by localedef(1)
from Single UNIX(R) Spec. so i don't implements chrtbl(1)'s LC_NUMERIC facility,
no need to update manpage.

but i added new feature to mklocale(1). it is also the zombie from
4.4BSD/FreeBSD ;-<
because i don't have enough time to implement localedef(1),(mainly
stateful encoding difficultiness).
thanks for wiz, updating manpage!


very truly yours.
--
Takehiko NOZAKI <tnozaki%NetBSD.org@localhost>

2009/1/2, Jeremy C. Reed <reed%reedmedia.net@localhost>:
> (I removed gnats from my reply.)
>
> Thank you much for your work on this.
>
> I am interested in writing a short news article about this for the NetBSD
> website.
>
> From the non-developer point of view, any examples of what NetBSD
> end-users / administrators can do to notice or take advantage of the new
> improved LC_MONETARY, LC_NUMERIC, LC_TIME, LC_MESSAGES?
>
> (I see a few uses of LC_TIME in our userland.)
>
> And for NetBSD developers, what can we do to help build upon these
> improvements?
>
> And does the chrtbl.8 manual page need to be updated? (It discusses that
> LC_NUMERIC is not fully implemented.)
>


-- 
Takehiko NOZAKI<takehiko.nozaki%gmail.com@localhost>