php-i18n Digest 21 Feb 2006 06:16:32 -0000 Issue 312
Topics (messages 936 through 938):
Re: remaining tasks
936 by: Dmitry Stogov
Ideas for a portable string api
937 by: Dmitry Stogov
938 by: Andrei Zmievski
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Wednesday I'll available till 16:00 GMT.
Dmitry.
> -----Original Message-----
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 19, 2006 2:11 AM
> To: Tex Texin; 'Derick Rethans'; 'Marcus Boerger'
> Cc: 'Dmitry Stogov'; [email protected]
> Subject: RE: [PHP-I18N] remaining tasks
>
>
> I probably won't be able to make it until 1:30pm, although you can
> start and I'll join.
> Dmitry, can you make that time?
>
> Andi
>
> At 01:37 AM 2/17/2006, Tex Texin wrote:
> >thanks guys, 2100gmt is fine. Let's see if that is good for others.
> >
> >Tex Texin
> >Internationalization Architect, Yahoo! Inc.
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Derick Rethans [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, February 17, 2006 1:13 AM
> > > To: Marcus Boerger
> > > Cc: Tex Texin; 'Dmitry Stogov'; 'Andi Gutmans';
> > > [email protected]
> > > Subject: Re: [PHP-I18N] remaining tasks
> > >
> > >
> > > On Fri, 17 Feb 2006, Marcus Boerger wrote:
> > >
> > > > generally i am not available until 2030GMT and on
> > > wednesday i am not
> > > > available before 2100GMT. GMT Evening hours is no
> problem for me.
> > > > However i am not that important for i18n meeting i guess.
> > >
> > > 2100GMT on wednesday would work for me too (that is 1300PST,
> > > 1600EST).
> > >
> > > regards,
> > > Derick
> > >
> > > --
> > > Derick Rethans
> > > http://derickrethans.nl | http://ez.no | http://xdebug.org
> > >
> > >
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--- End Message ---
--- Begin Message ---
Hi Andrei,
We decide to use the same type for str.len (now int) and ustr.len (now
int32_t, it comes from ICU).
I prefer to make both of them - int.
Any reclaims? I plan to do it at Thursday.
Thanks. Dmitry.
> -----Original Message-----
> From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 16, 2006 12:12 PM
> To: [email protected]
> Subject: RE: [PHP-I18N] Ideas for a portable string api
>
>
> Hi,
>
> After reviewing Marcus ideas, some experiments and speaking
> with Andrei. I propose the following solutions:
>
> 1) We will not use any kind of unicode literals in C code (no
> L"foo" no "f\0o\0o\0\0"), Because L"" is not portable and
> "f\0.." looks to ugly.
>
> 2) We will change "zval" structure to make
> "zval.value.str.len" and "zval.value.ustr.len" of the same
> type. This will allow optimize Z_UNISTR() and Z_UNILEN()
> macros. They will
>
> #define Z_UNISTR(z) ((void*)(Z_STRVAL(z)))
> #define Z_UNILEN(z) ((void*)(Z_STRLEN(z)))
>
> Instead of
>
> #define Z_UNISTR(z)
> Z_TYPE(z)==IS_UNICODE?(char*)Z_USTRVAL(z):Z_STRVAL(z)
> #define Z_UNILEN(z)
> Z_TYPE(z)==IS_UNICODE?(int)Z_USTRLEN(z):Z_STRLEN(z)
>
> 3) I don't like to break source compatibility with
> modification of "zval" layout as Marcus suggested. We will
> pass string/unicode values near in the same way as do today.
> As three values - zend_uchar type, void* str, int len. But we
> will create a set of the following macros to do it with less overhead.
>
> #define S_TYPE(x) _type_##x
> #define S_UNIVAL(x) _val_##x
> #define S_UNILEN(x) _len_##x
> #define S_STRVAL(x) ((char*)S_UNIVAL(x))
> #define S_USTRVAL(x) ((UChar*)S_UNIVAL(x))
> #define S_STRLEN(x) S_UNILEN(x)
> #define S_USTRLEN(x) S_UNILEN(x)
>
> #define S_ARG(x) zend_uchar S_TYPE(x), void
> *S_UNIVAL(x), int
> S_UNILEN(x)
>
> #define S_PASS(x) S_TYPE(x), S_UNIVAL(x), S_UNILEN(x)
>
> #define Z_STR_PASS(x) Z_TYPE(x), Z_UNIVAL(x), Z_UNILEN(x)
> #define Z_STR_PASS_P(x) Z_TYPE_P(x), Z_UNIVAL_P(x),
> Z_UNILEN_P(x)
> #define Z_STR_PASS_PP(x) Z_TYPE_PP(x), Z_UNIVAL_PP(x),
> Z_UNILEN_PP(x)
>
> Then most zend_u_... Functions must be rewriten with these macros
>
> Foe example:
>
> ZEND_API int zend_u_lookup_class(S_ARG(name), zend_class_entry ***ce
> TSRMLS_DC)
> {
> return zend_u_lookup_class_ex(S_PASS(name), 1, ce TSRMLS_CC); }
>
> Instead of
>
> ZEND_API int zend_u_lookup_class(zend_uchar type, void *name,
> int name_length, zend_class_entry ***ce TSRMLS_DC) {
> return zend_u_lookup_class_ex(type, name, name_length,
> 1, ce TSRMLS_CC); }
>
> Any objections, additions?
>
> Thanks. Dmitry.
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--- End Message ---
--- Begin Message ---
I prefer to use fixed integer type, int32_t.
-Andrei
On Feb 20, 2006, at 11:11 AM, Dmitry Stogov wrote:
Hi Andrei,
We decide to use the same type for str.len (now int) and ustr.len (now
int32_t, it comes from ICU).
I prefer to make both of them - int.
Any reclaims? I plan to do it at Thursday.
Thanks. Dmitry.
-----Original Message-----
From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 16, 2006 12:12 PM
To: [email protected]
Subject: RE: [PHP-I18N] Ideas for a portable string api
Hi,
After reviewing Marcus ideas, some experiments and speaking
with Andrei. I propose the following solutions:
1) We will not use any kind of unicode literals in C code (no
L"foo" no "f\0o\0o\0\0"), Because L"" is not portable and
"f\0.." looks to ugly.
2) We will change "zval" structure to make
"zval.value.str.len" and "zval.value.ustr.len" of the same
type. This will allow optimize Z_UNISTR() and Z_UNILEN()
macros. They will
#define Z_UNISTR(z) ((void*)(Z_STRVAL(z)))
#define Z_UNILEN(z) ((void*)(Z_STRLEN(z)))
Instead of
#define Z_UNISTR(z)
Z_TYPE(z)==IS_UNICODE?(char*)Z_USTRVAL(z):Z_STRVAL(z)
#define Z_UNILEN(z)
Z_TYPE(z)==IS_UNICODE?(int)Z_USTRLEN(z):Z_STRLEN(z)
3) I don't like to break source compatibility with
modification of "zval" layout as Marcus suggested. We will
pass string/unicode values near in the same way as do today.
As three values - zend_uchar type, void* str, int len. But we
will create a set of the following macros to do it with less
overhead.
#define S_TYPE(x) _type_##x
#define S_UNIVAL(x) _val_##x
#define S_UNILEN(x) _len_##x
#define S_STRVAL(x) ((char*)S_UNIVAL(x))
#define S_USTRVAL(x) ((UChar*)S_UNIVAL(x))
#define S_STRLEN(x) S_UNILEN(x)
#define S_USTRLEN(x) S_UNILEN(x)
#define S_ARG(x) zend_uchar S_TYPE(x), void
*S_UNIVAL(x), int
S_UNILEN(x)
#define S_PASS(x) S_TYPE(x), S_UNIVAL(x), S_UNILEN(x)
#define Z_STR_PASS(x) Z_TYPE(x), Z_UNIVAL(x), Z_UNILEN(x)
#define Z_STR_PASS_P(x) Z_TYPE_P(x), Z_UNIVAL_P(x),
Z_UNILEN_P(x)
#define Z_STR_PASS_PP(x) Z_TYPE_PP(x), Z_UNIVAL_PP(x),
Z_UNILEN_PP(x)
Then most zend_u_... Functions must be rewriten with these macros
Foe example:
ZEND_API int zend_u_lookup_class(S_ARG(name), zend_class_entry ***ce
TSRMLS_DC)
{
return zend_u_lookup_class_ex(S_PASS(name), 1, ce TSRMLS_CC); }
Instead of
ZEND_API int zend_u_lookup_class(zend_uchar type, void *name,
int name_length, zend_class_entry ***ce TSRMLS_DC) {
return zend_u_lookup_class_ex(type, name, name_length,
1, ce TSRMLS_CC); }
Any objections, additions?
Thanks. Dmitry.
--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
