Re: [PHP-DEV] RFC: Removing PHP tags

2012-03-31 Thread Moriyoshi Koizumi
Ok, I'll try to fix that part. Thanks for the correction. Moriyoshi On Sun, Apr 1, 2012 at 11:29 AM, Rasmus Lerdorf wrote: > On Mar 31, 2012, at 6:59 PM, Moriyoshi Koizumi wrote: > >> Hi, >> >> I wrote a RFC that proposes removal of PHP tags.  There is actually &

[PHP-DEV] RFC: Removing PHP tags

2012-03-31 Thread Moriyoshi Koizumi
Hi, I wrote a RFC that proposes removal of PHP tags. There is actually strong public demand for it, and I also think it is necessary to leverage PHP to a genuine, modern scripting language. http://wiki.php.net/rfc/nophptags Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] [RFC] 5.4 features for vote (long)

2011-06-20 Thread Moriyoshi Koizumi
On Mon, Jun 20, 2011 at 8:39 PM, Derick Rethans wrote: >> 8. Cli web server. Built-in mini-HTTP server run directly from PHP binary. >> Assigned: Moriyoshi Koizumi > > I'd really like to see that one. I thought the patch was already > committed? Not yet. I'm gon

Re: [PHP-DEV] [RFC] 5.4 features for vote (long)

2011-06-20 Thread Moriyoshi Koizumi
. Does not include any new JSON-like syntax, etc. - just making > '[' be 'array(' and ']' be ')' in that context. > > 7. "Disable POST data processing" INI option. > Assigned: Gustavo Lopes > > 8. Cli web server. Built-in mini-

Re: [PHP-DEV] streams problem in 5.3

2011-03-04 Thread Moriyoshi Koizumi
Hmm, it has already supported through ZEND_HANDLE_STREAM. So then, changing the interface of fopen_function to return zend_stream instead of FILE* should be fine. Moriyoshi On 2011/03/05, at 3:05, Moriyoshi Koizumi wrote: > It looks like the only solution is define a new stream type

Re: [PHP-DEV] streams problem in 5.3

2011-03-04 Thread Moriyoshi Koizumi
It looks like the only solution is define a new stream type for zend_stream that delegates stream operations to user-defined callbacks. Moriyoshi On 2011/03/04, at 10:26, Stas Malyshev wrote: > Hi! > > I try to do some complex code with custom streams and I have discovered the > following pro

Re: [PHP-DEV] RFC: built-in web server in CLI.

2011-03-03 Thread Moriyoshi Koizumi
On Fri, Mar 4, 2011 at 11:17 AM, Christopher Jones wrote: > > > On 03/02/2011 12:55 PM, Moriyoshi Koizumi wrote: >> >> Hi, >> >> Just to let you know that I wrote a RFC about built-in web server >> feature with which PHP can serve contents without a help

Re: [PHP-DEV] RFC: built-in web server in CLI.

2011-03-03 Thread Moriyoshi Koizumi
Hi, 2011/3/3 Ángel González : > Moriyoshi Koizumi wrote: >>> Regarding the patch (https://gist.github.com/835698): >>> I don't see a switch to disable the internal parse on configure. >> I don't see any obvious reason it should be able to be turned off &

Re: [PHP-DEV] RFC: built-in web server in CLI.

2011-03-03 Thread Moriyoshi Koizumi
Hi, On Thu, Mar 3, 2011 at 3:35 PM, Alexey Zakhlestin wrote: > On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi wrote: >> Hi, >> >> Just to let you know that I wrote a RFC about built-in web server >> feature with which PHP can serve contents without a help of web

[PHP-DEV] Re: Reverting ext/mbstring patch

2011-03-03 Thread Moriyoshi Koizumi
try Stogov wrote: > Hi Moriyoshi, > > OK, I thought the email was lost, so ignore the email I just resent. > > In general I like your patch and I would glad to see it fixed. > > I already tried to make some fixes. > See the attached patch. > > Thanks. Dmitry. > > O

Re: [PHP-DEV] RFC: built-in web server in CLI.

2011-03-02 Thread Moriyoshi Koizumi
2011/3/3 Ángel González : > Moriyoshi Koizumi wrote: >> Hi, >> >> Just to let you know that I wrote a RFC about built-in web server >> feature with which PHP can serve contents without a help of web >> servers.  That would be handy for development purpose. >>

[PHP-DEV] RFC: built-in web server in CLI.

2011-03-02 Thread Moriyoshi Koizumi
Hi, Just to let you know that I wrote a RFC about built-in web server feature with which PHP can serve contents without a help of web servers. That would be handy for development purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Regards, Moriyoshi -- PHP Intern

[PHP-DEV] Re: Reverting ext/mbstring patch

2011-03-02 Thread Moriyoshi Koizumi
Hey, I think I can fix it somehow. Please don't be haste with it. I am going to look into it. Moriyoshi On Tue, Mar 1, 2011 at 11:35 PM, Dmitry Stogov wrote: > Hi, > > I'm going to revert Moriyoshi patch from December and some following fixes. > > I like the idea of the patch, but it just doe

[PHP-DEV] Re: --enable-zend-multibyte

2010-12-06 Thread Moriyoshi Koizumi
On Tue, Dec 7, 2010 at 5:57 AM, Dmitry Stogov wrote: > On 12/06/2010 08:25 PM, Moriyoshi Koizumi wrote: >> >> On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov  wrote: >>> >>> Hi Moriyoshi, >>> >>> On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote: &

Re: [PHP-DEV] ext/mbstring dependencies

2010-12-06 Thread Moriyoshi Koizumi
Hi, The patch almost looks good to me, but we should be more careful about introducing a set of hook points into the API. I think it'd be great if the multipart parser portion was rewritten so that it would only call the Zend multibyte API's despite a slight performance drawback. Regards, Moriyo

[PHP-DEV] Re: --enable-zend-multibyte

2010-12-06 Thread Moriyoshi Koizumi
On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov wrote: > Hi Moriyoshi, > > On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote: >> >> Hi, >> >> How about using the value of mbstring.script_encoding to determine >> whether to enable the encoding conversion featur

[PHP-DEV] Re: --enable-zend-multibyte

2010-12-06 Thread Moriyoshi Koizumi
Hi, How about using the value of mbstring.script_encoding to determine whether to enable the encoding conversion feature? If the value is the same as that of mbstring.internal_encoding, then no conversion should be needed in the first place. Besides we can define some singular value like "none"

Re: [PHP-DEV] Using default_charset for htmlspecialchars() and others

2010-05-03 Thread Moriyoshi Koizumi
Hi, I am under the impression that we have to provide an alternative to htmlspecialchars() that incorporates the following ideas: - Shorter function name html_escape() for example. _h() would be much more preferable in terms of preventing XSS ;-p - Using default_charset as the default encoding

[PHP-DEV] Autoboxing in PHP

2010-05-03 Thread Moriyoshi Koizumi
Hey, Just to let you know about a new RFC for adding autoboxing feature in PHP. Look at http://wiki.php.net/rfc/autoboxing . Regards, Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php and multithreading (additional arguments)

2010-04-05 Thread Moriyoshi Koizumi
On Mon, Apr 5, 2010 at 7:17 PM, Alexey Zakhlestin wrote: > > On 05.04.2010, at 13:46, Moriyoshi Koizumi wrote: > >> I used to play with TSRM days ago and successfully implemented >> userland threading support using GNU Pth.  It's just a proof of >> concept and I

Re: [PHP-DEV] php and multithreading (additional arguments)

2010-04-05 Thread Moriyoshi Koizumi
I used to play with TSRM days ago and successfully implemented userland threading support using GNU Pth. It's just a proof of concept and I did it for fun. If interested, check out http://github.com/moriyoshi/php-src/tree/PHP_5_3-threading/ and read http://github.com/moriyoshi/php-src/blob/PHP_5

Re: [PHP-DEV] Performance improvements

2010-03-25 Thread Moriyoshi Koizumi
Hi, On Thu, Mar 25, 2010 at 8:41 AM, Stanislav Malyshev wrote: > Hi! > >> Wouldn't it suffice to add a field for the hash value and a flag that >> indicates its validity to zval instead of appending zend_literal >> everywhere? > > Enlarging zval would be costly (the engine uses tons of zvals) and

Re: [PHP-DEV] Performance improvements

2010-03-24 Thread Moriyoshi Koizumi
Hi, Wouldn't it suffice to add a field for the hash value and a flag that indicates its validity to zval instead of appending zend_literal everywhere? Moriyoshi On Wed, Mar 24, 2010 at 11:12 PM, Zeev Suraski wrote: > Hi, > > Over the last few weeks we've been working on several ideas we had for

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Moriyoshi Koizumi
On Mon, Mar 15, 2010 at 6:25 AM, Herman Radtke wrote: >> Oh no .. another dangerous topic. Again we have been there even before the >> switch. The idea is to keep the centralized repo on svn, because the masses >> know how it works, the tools are widely available and we have plenty of >> experi

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Moriyoshi Koizumi
On Sun, Mar 14, 2010 at 11:23 PM, Jordi Boggiano wrote: > On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev wrote: >> UTF8 also takes 4 bytes for representing characters in the higher bit >> planes, as quite a lot of bits are lost for every char in order to describe >> how long the code point is, a

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
On Sun, Mar 14, 2010 at 1:57 AM, Derick Rethans wrote: > - in the meanwhile, start working on patching in back Unicode support, >  but in small steps. Exactly which things, and how we'd have to find >  out. But I do think it needs to be a *core* language feature, and not >  simply solved by exten

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
It looks like I stripped off too much. Attached is the right one. Moriyoshi On Sun, Mar 14, 2010 at 12:41 AM, Moriyoshi Koizumi wrote: > Surprisingly, It can be done quite easily with the current object > handler infrastructure. > > Moriyoshi > > On Sun, Mar 14, 2010 at 12:

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
Surprisingly, It can be done quite easily with the current object handler infrastructure. Moriyoshi On Sun, Mar 14, 2010 at 12:08 AM, Pierre Joye wrote: > On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi wrote: > >> I don't totally agree with what is being said here, but I

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
On Sat, Mar 13, 2010 at 6:07 PM, Chen Ze wrote: > I think unicode should only care for string handling. Formatting > numbers should not be the thing that unicode cares. Unicode is a > standard for text, not for text or number formatting. > > Back to the days we don't have unicode, the number forma

Re: [PHP-DEV] PHP 6

2010-03-13 Thread Moriyoshi Koizumi
On Sat, Mar 13, 2010 at 8:09 PM, Lester Caine wrote: > Handling unicode CONTENT is not the problem here. People nowadays expect to > be able to use their own language to write code, and create functions using > words that they recognize. In databases, table and field names are now > expected to su

Re: [PHP-DEV] PHP 6

2010-03-12 Thread Moriyoshi Koizumi
make a serious internaltionalized application. Moriyoshi On Sat, Mar 13, 2010 at 3:34 AM, Derick Rethans wrote: > On Fri, 12 Mar 2010, Hannes Magnusson wrote: > >> On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi wrote: >> > I'd love to see my brand-new mbstrin

Re: [PHP-DEV] PHP 6

2010-03-12 Thread Moriyoshi Koizumi
I'd love to see my brand-new mbstring implementation in the release. Dropping mbstring completely won't be any good because lots of applications rely on it, but I don't really want to maintain the funky library bundled with it. Moriyoshi On Fri, Mar 12, 2010 at 2:22 AM, Rasmus Lerdorf wrote: > A

Re: [PHP-DEV] adding GB18030 support for mbstring

2010-02-01 Thread Moriyoshi Koizumi
2010/2/1 KITAZAKI Shigeru : > * php_syslog.patch >  syslog() function cannot properly send UTF-8 strings to event log on >  Windows. This patch changes the internal API. We, however, must set >  UTF-8 on 'mbstring.internal_incoding'. >  In addition, this changes the severity of 'LOG_ERR' from event

[PHP-DEV] Re: [PHP-I18N] adding GB18030 support for mbstring

2010-01-31 Thread Moriyoshi Koizumi
Kitazaki-san, First thank you for your effort. But, I am under the impression that the conversion table looks too huge to include in a distribution (>30MB). Is there any way to get this more compressed? BTW, I created an extension that is near-compatible with mbstring and based on ICU that of co

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-08-03 Thread Moriyoshi Koizumi
On Tue, Aug 4, 2009 at 2:47 AM, Stanislav Malyshev wrote: >> And yes, it's worth providing separate conversion system.  You might >> not be aware of it, but there are several sets of different character >> sets, each of which is often represented with a specific encoding >> scheme.  Shift_JIS is o

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-08-03 Thread Moriyoshi Koizumi
On Sat, Aug 1, 2009 at 9:02 AM, Stanislav Malyshev wrote: > Hi! > >> They calculate the total width of a string based on "east asian width" >> property, which is still valid to give a rough measurement of the >> rendered string. > > OK, I guess if it's some kind of special calculation that doesn't

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
Hi, On Sat, Aug 1, 2009 at 1:37 AM, Stanislav Malyshev wrote: > Hi! > >>> mb_str* - shouldn't you in 6 just convert them to unicode and do all >>> string >>> operations with Unicode strings? Also, in 5 isn't there some intersection >>> with grapheme_* functions? >> >> mb_strwidth() and mb_strimwid

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Fri, Jul 31, 2009 at 5:24 PM, Moriyoshi Koizumi wrote: >> mb_str* - shouldn't you in 6 just convert them to unicode and do all string >> operations with Unicode strings? Also, in 5 isn't there some intersection >> with grapheme_* functions? > > mb_strwidth() a

Re: [PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Fri, Jul 31, 2009 at 2:37 AM, Stanislav Malyshev wrote: > Hi! > >> Aren't there any interests on this? If you think PHP 6 is gonna cover >> all of the functionality that allegedly-cruft mbstring currently >> provides, that is almost wrong :-p > > Could you please explain why PHP6 doesn't provide

Re: [PHP-DEV] Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Thu, Jul 30, 2009 at 8:05 PM, Niel Archer wrote: >> Implemented functions: >> >> - mb_ereg() >> - mb_ereg_replace() > > as ereg functions are deprecated in 5.3, are these still needed? mb_ereg_XXX() have nothing to do with the plain ereg functions. They are named so purely for the historical re

Re: [PHP-DEV] Alternative mbstring implementation using ICU

2009-07-31 Thread Moriyoshi Koizumi
On Thu, Jul 30, 2009 at 7:21 PM, Alexey Zakhlestin wrote: > 2009/7/26 Moriyoshi Koizumi : > >> - mb_ereg_search(), mb_ereg_search_getpos(), mb_ereg_search_getregs(), >>  mb_ereg_search_init(), mb_ereg_search_pos(), mb_ereg_search_regs() and >>  mb_ereg_search_setpos() >

[PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-29 Thread Moriyoshi Koizumi
Aren't there any interests on this? If you think PHP 6 is gonna cover all of the functionality that allegedly-cruft mbstring currently provides, that is almost wrong :-p Moriyoshi On Tue, Jul 28, 2009 at 5:41 PM, Moriyoshi Koizumi wrote: > I set up a RFC page for this in wiki.php.net.

[PHP-DEV] Re: Alternative mbstring implementation using ICU

2009-07-28 Thread Moriyoshi Koizumi
I set up a RFC page for this in wiki.php.net. Here it goes: http://wiki.php.net/rfc/altmbstring Moriyoshi 2009/7/26 Moriyoshi Koizumi : > Hi there, > > I almost finished an alternative implementation of mbstring that uses > ICU instead of the exotic libmbfl in hope of replacing the

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

2009-07-28 Thread Moriyoshi Koizumi
Incorporating the changes and merges across the branches into one commit under a sparse-layouted local copy doesn't do the book-keeping against svn:mergeinfo. That's why I suppose it is not a good idea. Moriyoshi On Tue, Jul 28, 2009 at 7:44 AM, Gwynne Raskind wrote: > On Jul 27, 2009, at 6:31 P

[PHP-DEV] Re: ext/iconv/tests/bug16069.phpt

2009-07-28 Thread Moriyoshi Koizumi
That is a test that is involved in the iconv's transilteration feature, the behavior of which may vary by the platform you use. I guess we don't actually need to test it then. Moriyoshi On Tue, Jul 28, 2009 at 12:27 PM, Rasmus Lerdorf wrote: > Moriyoshi, or someone who knows CP932 and EUC-JP, co

Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ext/gd/ libgd/gdft.c tests/bug48555.phpt tests/bug48732.phpt tests/bug48801.phpt

2009-07-27 Thread Moriyoshi Koizumi
Just to be sure, is there any consensus on this? I thought I should use svn merge. Moriyoshi On Tue, Jul 28, 2009 at 12:30 AM, David Soria Parra wrote: > On 2009-07-27, Takeshi Abe wrote: >> Log: >> MFH: fixed #48732 (TTF Bounding box wrong for letters below baseline) and >> #48801 (Problem wit

[PHP-DEV] Alternative mbstring implementation using ICU

2009-07-26 Thread Moriyoshi Koizumi
Hi there, I almost finished an alternative implementation of mbstring that uses ICU instead of the exotic libmbfl in hope of replacing the current one for 5.4 (and possibly, 6.0.) Although there are admittingly some known incompatibilities that need extra libraries to resolve them besides a numbe

Re: [PHP-DEV] Segfault while looping through hash table

2009-05-14 Thread Moriyoshi Koizumi
On Fri, May 15, 2009 at 12:31 PM, Farley Knight wrote: > zend_hash_internal_pointer_reset(Z_ARRVAL(zhash)); > > printf("This hash table has %d entries\n", > zend_hash_num_elements(Z_ARRVAL(zhash))); > > int current = 0; > > while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)&value) >

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-05-14 Thread Moriyoshi Koizumi
While I am stil wondering why we could not stop this kind of mess before the release, we should also revert the default for 5.3. There's no point making the behavior different between releases. Moriyoshi On Fri, May 15, 2009 at 5:10 AM, Andrei Zmievski wrote: > Ilia Alshanetsky wrote: >> >> Andr

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/iconv iconv.c

2009-05-14 Thread Moriyoshi Koizumi
Ilia, do you still see any problem merging this to 5.2? Moriyoshi On Sat, Apr 11, 2009 at 6:16 PM, Hannes Magnusson wrote: > Ilia? > > I guess the chances of getting this merged Moriyoshi will increase by > 100% if you have a testcase.. > > -Hannes > > On Tue, Mar 17,

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-05-14 Thread Moriyoshi Koizumi
a number of crucial fixes and if your comments are > validated via user feedback we can adjust the values with 5.2.10 that can be > repackaged fairly rapidly. IMHO the current functionality is desired and is > acceptable. > > Ilia Alshanetsky > > > > > On 26-Feb-09, at 1:5

Re: [PHP-DEV] request for comments on threadsafe / multi-thread enabled Embed2 SAPI

2009-03-26 Thread Moriyoshi Koizumi
Isn't it better to avoid any behaviour-changing #define's in a header file? I mean the following series of lines in php_embed2.h: /* we control char* lifetime of smart_str as we allow it to cross request boundaries */ #define SMART_STR_USE_REALLOC 1 /* we use bigger numbers than default as script

Re: [PHP-DEV] max_execution_time and async signal handling in apache2handler

2009-03-15 Thread Moriyoshi Koizumi
i Moriyoshi, > > Moriyoshi Koizumi wrote: >> >> Hi, >> >> I got a bug report on the Japanese PHP user's list that states free() >> aborts within the timer signal handler due to reentrance to the >> function when max_execution_time takes effect and the signal

[PHP-DEV] max_execution_time and async signal handling in apache2handler

2009-03-15 Thread Moriyoshi Koizumi
Hi, I got a bug report on the Japanese PHP user's list that states free() aborts within the timer signal handler due to reentrance to the function when max_execution_time takes effect and the signal occurs within the same libc function. The reporter also states he uses apache2handler, which doesn'

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
as > possible as it introduces a number of crucial fixes and if your comments are > validated via user feedback we can adjust the values with 5.2.10 that can be > repackaged fairly rapidly. IMHO the current functionality is desired and is > acceptable. > > Ilia Alshanetsky > > &

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
On Fri, Feb 27, 2009 at 3:58 AM, Moriyoshi Koizumi wrote: > 1. array_unique() has never been supposed to handle values other than > strings. That's how bug #10658 is handled. That's not what I really wanted to mean. I should have said "not supposed to handle valu

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
Robin Burchell wrote: > On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi wrote: >> So, in what point do you guys think of this change as valid? >> >> Moriyoshi > > Is there any known examples of code broken by this, or is it a more > academic than practical p

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

2009-02-26 Thread Moriyoshi Koizumi
So, in what point do you guys think of this change as valid? Moriyoshi On Thu, Feb 26, 2009 at 11:36 PM, Antony Dovgal wrote: > On 26.02.2009 17:19, Ilia Alshanetsky wrote: >> Let's reach a conclusion by end of day (EST time) so release can either be >> made or >> delayed. > > +0 > > Just go ah

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-25 Thread Moriyoshi Koizumi
Last call: any more objections? Moriyoshi On Thu, Feb 19, 2009 at 11:52 AM, Moriyoshi Koizumi wrote: > On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski > wrote: >> Moriyoshi Koizumi wrote: >>> >>> As I said earlier, the function is never supposed to be used w

Re: [PHP-DEV] FD_SETSIZE limitation

2009-02-19 Thread Moriyoshi Koizumi
Robin Burchell wrote: > On Thu, Feb 19, 2009 at 10:24 PM, Andrei Zmievski > wrote: >> Can someone explain why ext/sockets and also stream socket functions care >> about FD_SETSIZE? > > They care, because they use the select(2) syscall, which cares about > FD_SETSIZE. > select(2) itself can ha

Re: [PHP-DEV] FD_SETSIZE limitation

2009-02-19 Thread Moriyoshi Koizumi
That's because struct fd_set, which is manipulated by FD_SET, is a struct that contains a fixed-size array. Moriyoshi Andrei Zmievski wrote: > Can someone explain why ext/sockets and also stream socket functions > care about FD_SETSIZE? > > # define PHP_SAFE_FD_SET(fd, set) do { if (fd < FD_SE

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-18 Thread Moriyoshi Koizumi
On Thu, Feb 19, 2009 at 3:14 PM, Ian Eure wrote: > On Feb 18, 2009, at 6:52 PM, Moriyoshi Koizumi wrote: > >> On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski >> wrote: >>> >>> Moriyoshi Koizumi wrote: >>>> >>>> As I said earlier,

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-18 Thread Moriyoshi Koizumi
On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski wrote: > Moriyoshi Koizumi wrote: >> >> As I said earlier, the function is never supposed to be used with >> objects. Therefore, we cannot declare it to be broken, and any change >> to the behavior anyway leads to a hu

Re: [PHP-DEV] Re: Bug #46701

2009-02-18 Thread Moriyoshi Koizumi
merged, then bug #46701 should be reverted from the 5.2 branch. Moriyoshi On Wed, Feb 18, 2009 at 8:28 PM, zoe wrote: > Moriyoshi Koizumi wrote: >>>>> I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was >>>>> changed by the fix for bug #42868, rig

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-17 Thread Moriyoshi Koizumi
In addition, we should look at similar comparison-involved array functions such as array_intersect, array_diff and so on, otherwise it's gonna be a mess. Moriyoshi On Wed, Feb 18, 2009 at 11:43 AM, Moriyoshi Koizumi wrote: > On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-17 Thread Moriyoshi Koizumi
On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski wrote: > SORT_STRING can only reliably deal with strings - its behavior on non-string > type is basically broken. Unless we agree that PHP is Tcl (strings are the > only type), then SORT_REGULAR makes much more sense to me, and evidently > others.

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-17 Thread Moriyoshi Koizumi
Anyone's thoughts on this? I'm thinking of re-reverting in 48 hours without further objections. Moriyoshi On Sun, Feb 15, 2009 at 11:48 PM, Moriyoshi Koizumi wrote: > Ilia Alshanetsky wrote: >> I've discussed this issue with Andrei at least a month ago (if not >&

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c

2009-02-15 Thread Moriyoshi Koizumi
Moriyoshi > > On 14-Feb-09, at 9:12 PM, Moriyoshi Koizumi wrote: > >> So, what are RM's thoughts on this? My points are: >> >> 1. Making SORT_REGULAR default *actually* broke existing code. >> 2. Adding the second argument addressed the problem enough that th

Re: [PHP-DEV] Re: Bug #46701

2009-02-14 Thread Moriyoshi Koizumi
ess this issue? > > > On 12-Feb-09, at 3:56 PM, Moriyoshi Koizumi wrote: > >> See the results of the following on 5.2.6, 5.2.9rc2 and 5.3: >> >> php -r '$a[1e100] = 1; var_dump($a);' >> >> 5.2.6: >> array(1) { >> [-2147483648]=> &

[PHP-DEV] Re: Bug #46701

2009-02-12 Thread Moriyoshi Koizumi
what we expect, and this problem should be addressed in 5.3 with the 5.2's behavior unchanged. Moriyoshi On Fri, Feb 13, 2009 at 1:48 AM, Moriyoshi Koizumi wrote: > Hey, > > I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was > changed by the fix for bug #42

[PHP-DEV] Bug #46701

2009-02-12 Thread Moriyoshi Koizumi
Hey, I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was changed by the fix for bug #42868, right? If so, this patch shouldn't be MFH'ed as the #42868 patch was not merged although I didn't remember any discussion on this. See also: http://marc.info/?l=php-internals&m=12079972092

Re: [PHP-DEV] [PATCH] Bug #46806 - mb_strimwidth

2009-01-04 Thread Moriyoshi Koizumi
Hi, This behavior seems strange, but the rationale of this function is that the (east asian) width of the resulting string does not exceed the specified value so that it would fit to a fixed sized box when rendered in the browser, assuming the string would be displayed with a monospace font.

Re: [PHP-DEV] Need some help about using Boost.PHP to make extensions

2008-11-19 Thread Moriyoshi Koizumi
Please redirect your question to me. Boost.PHP is not an official part of the PHP project. Moriyoshi On Wed, Nov 19, 2008 at 2:13 AM, Chris Jiang <[EMAIL PROTECTED]> wrote: > Hi all, it's been a while since my last thread. I've been playing around > with Boost.PHP these days, and find it pretty m

Re: [PHP-DEV] Extending PHP with C++ (Newbie Question)

2008-11-16 Thread Moriyoshi Koizumi
Hey, Don't forget to have a look at Boost.PHP :) http://github.com/moriyoshi/boost.php/wikis Moriyoshi On Sun, Nov 16, 2008 at 12:11 AM, Chris Jiang <[EMAIL PROTECTED]> wrote: > Hi all, it's my first time posting in this mailing list. > > I've been trying to make a PHP extension for my project,

Re: [PHP-DEV] quick polls for 5.3

2008-11-15 Thread Moriyoshi Koizumi
On Thu, Nov 13, 2008 at 4:14 AM, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > 1) ext/mhash in 5.3. > I) enable ext/hash by default +1 > II) remove ext/mhash +1 > 2) deprecate ereg*. +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate STDIN

Re: [PHP-DEV] Inconsistencies in 5.3

2008-08-06 Thread Moriyoshi Koizumi
Stanislav Malyshev wrote: Hi! language syntax, whereas the "use" construct after the argument list is inconsistent with the ordinary function definition unless my proposal Because it is _not_ an ordinary function definition. It's like saying '+' is "inconsistent" with '-' because $a+$b=$b+$

Re: [PHP-DEV] Inconsistencies in 5.3

2008-08-06 Thread Moriyoshi Koizumi
Stanislav Malyshev wrote: Hi! What a nitpicking :) So would I say that the global statement is inconsistent with static because it doesn't allow assignments within the statement :p Sure it is. That's just another thing to show all this "consistency" talk is blown way out of proportion long

Re: [PHP-DEV] Inconsistencies in 5.3

2008-08-06 Thread Moriyoshi Koizumi
Stanislav Malyshev wrote: Hi! function ($arg) { use $a, &$b; Note that neither static not global allow & inside definitions, so from "consistency" point of view it doesn't work. What a nitpicking :) So would I say that the global statement is inconsistent with static because it doesn't al

Re: [PHP-DEV] Inconsistencies in 5.3

2008-08-05 Thread Moriyoshi Koizumi
Larry Garfield wrote: On Tuesday 05 August 2008 12:48:37 am Moriyoshi Koizumi wrote: I don't think there are many differences in ambiguity between $closure = function ($arg) { use $a; ... }; and $closure = function ($arg) use ($a) { }; Moriyoshi -- Moriyoshi Koizumi <[EMAIL P

Re: [PHP-DEV] Inconsistencies in 5.3

2008-08-04 Thread Moriyoshi Koizumi
entation had "lexical" keyword which worked as you are suggesting, but it was much unclear. I don't think there are many differences in ambiguity between $closure = function ($arg) { use $a; ... }; and $closure = function ($arg) use ($a) { }; Moriyoshi -- Moriyoshi Koizum

Re: [PHP-DEV] Inconsistencies in 5.3

2008-08-04 Thread Moriyoshi Koizumi
think the point is that PHP doesn't have the concept of compilation units unlike major namespaced programming languages such as C++ and Java. PHP so far chose to differentiate grammatical contexts with braces or blocked statements, so should namespace. Moriyoshi -- Moriyoshi Koizu

Re: [PHP-DEV] Const-correctness

2008-08-03 Thread Moriyoshi Koizumi
in this case. Moriyoshi -- Moriyoshi Koizumi <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Inconsistencies in 5.3

2008-08-03 Thread Moriyoshi Koizumi
suggest we disallow multiple namespace per file. And there is no technical reason and surely no other reason whatsoever to not have curly braces. If there is then we either fix that or went with the wrong approach. 3) __invokable, see Etiene's mail Best regards, Marcus -- Moriyoshi K

Re: [PHP-DEV] enabling everything by default

2008-08-02 Thread Moriyoshi Koizumi
Hi, Antony Dovgal wrote: Extensions enabled by default in 5.3: ctype date dom ereg fileinfo - new, untested. filter hash iconv json libxml pcre PDO pdo_sqlite Phar - new, untested posix Reflection session SimpleXML SPL SQLite sqlite3 - new, untested standard tokenizer xml xmlreader xmlwriter --

Re: [PHP-DEV] Introducing Boost.PHP - PHP Extensions in C++, in a minute

2008-07-30 Thread Moriyoshi Koizumi
Hi Marcus, Really? I haven't heard anything like that. MOriyoshi On 2008/07/30, at 16:19, Marcus Boerger wrote: Hello Stefan, which doesn't belong there either. marcus Wednesday, July 30, 2008, 9:14:07 AM, you wrote: Marcus Boerger schrieb: Hello Moriyoshi, actually you should pl

Re: [PHP-DEV] Introducing Boost.PHP - PHP Extensions in C++, in a minute

2008-07-29 Thread Moriyoshi Koizumi
Nope, but I'm thinking of proposing it as soon as I finish the documentation. Moriyoshi On 2008/07/29, at 23:00, troels knak-nielsen wrote: On Tue, Jul 29, 2008 at 2:58 PM, Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote: Hi folks, I created a library that may draw some attention

[PHP-DEV] Introducing Boost.PHP - PHP Extensions in C++, in a minute

2008-07-29 Thread Moriyoshi Koizumi
Hi folks, I created a library that may draw some attention. Boost.PHP is a set of macros and C++ classes that wrap around common Zend Engine structs that allow you to create a PHP extension in C++, in a very efficient way. Most notably, you no longer need most of the ZE macros and APIs li

[PHP-DEV] RFC question (Re: [PHP-DEV] [PATCH] Allow use($var..) statement ubiquitously)

2008-07-23 Thread Moriyoshi Koizumi
I would like to keep this as a RFC page in wiki.php.net. Are there any conventions or rules that I should keep in mind? (or just-not- supposed-to-do-that-because-your-proposal-is-stupid-and-will-never-be- accepted?) Moriyoshi On 2008/07/18, at 8:23, Moriyoshi Koizumi wrote: Hi, Attached

Re: [PHP-DEV] [PATCH] Allow use($var..) statement ubiquitously

2008-07-18 Thread Moriyoshi Koizumi
On 2008/07/18, at 19:06, Richard Quadling wrote: 2008/7/18 Moriyoshi Koizumi <[EMAIL PROTECTED]>: running test1.php ends up with two lines of "bar", surprisingly. This is somewhat confusing, but surely one of the things that could not ever be done. This might be a great h

Re: [PHP-DEV] [PATCH] Allow use($var..) statement ubiquitously

2008-07-18 Thread Moriyoshi Koizumi
That's one of the motivations for the patch. I never liked the new syntax, but if it was given a go, it should also be made consistent with the another part of the syntax. Oh, I just got one important thing in mind to mention; test1.php: test2.php: running test1.php ends up with two lin

[PHP-DEV] [PATCH] Allow use($var..) statement ubiquitously

2008-07-17 Thread Moriyoshi Koizumi
Hi, Attached are the patches that allow the "use" statement that was introduced with closures to appear within every function statement except method definitions. I think this feature is a good addition because it resolves inconsistency between closures and unticked functions. In a nutshe

Re: [PHP-DEV] --disable-mbregex in HEAD?

2008-07-15 Thread Moriyoshi Koizumi
Marcus Boerger wrote: > Hello Moriyoshi, > > (just for Derick answered here) > I never liked this. So imo we can simply get rid of this switch and enable > mbregex as soon as there is mbstring to begin with and regex stuff. Me neither. As far as I know, the switch exists just for historical reaso

[PHP-DEV] --disable-mbregex in HEAD?

2008-07-15 Thread Moriyoshi Koizumi
Hi there, (Yeah, it's been a long time.. Many of you might well have thought I'm dead :) This time I want to revisit the following issue: http://article.gmane.org/gmane.comp.php.devel/50681 Is there any point to disable mbregex alone instead of disabling the whole mbstring stuff? Unless the deci

Re: [PHP-DEV] implode() speedup in PHP4

2005-03-18 Thread Moriyoshi Koizumi
On 2005/03/19, at 6:14, Derick Rethans wrote: On Sat, 19 Mar 2005, Moriyoshi Koizumi wrote: We already have an optimisation in the 5.x branches. I think it is appliable to the 4.3 branch. 4.3 is only for bugfixes! It didn't mean that the fix should be in the 4.3. What was it that excited y

Re: [PHP-DEV] implode() speedup in PHP4

2005-03-18 Thread Moriyoshi Koizumi
On 2005/03/19, at 3:41, Alexander Valyalkin wrote: I've posted patch last summer http://www.zend.com/zend/week/pat/pat5.txt which imporves performance of implode() function in PHP4, but nobody doesn't commit it yet. Can anybody explain the reason? Because convert_to_string_ex() modifies the conte

Re: [PHP-DEV] reference issue

2005-03-17 Thread Moriyoshi Koizumi
On 2005/03/17, at 21:52, Lukas Smith wrote: Derick Rethans wrote: On Thu, 17 Mar 2005, Moriyoshi Koizumi wrote: That's expected behaviour. Have a look at http://bugs.php.net/20993 . Sorry, but this is not expected - it's a bug. I would also like to disagree. I think this is a huge inc

Re: [PHP-DEV] reference issue

2005-03-17 Thread Moriyoshi Koizumi
That's expected behaviour. Have a look at http://bugs.php.net/20993 . The problem can also be prevented by the following hack: // modifying and assining branch causes unexpexted results to $this->tree $metatree[$object_id] = (array)unserialize(serialize($branch)); Regards, Moriyoshi On 2005/03/17

Re: [PHP-DEV] HALT Patch

2005-03-11 Thread Moriyoshi Koizumi
Hi, I modified your patch so it can capture the position where the supposed data begins into the constant __HALT_PHP_PARSER__. There may be a problem with my patch if more than one require()'d / include()'d script contain __HALT_PHP_PARSER__, but it'd be quite handy if such an issue is resolved.

Re: [PHP-DEV] XML Bug #32001

2005-03-11 Thread Moriyoshi Koizumi
esn't make any sense if it doesn't work perfectly and we better deprecate it until some unicode-aware case folding function is available. Moriyoshi Rob Moriyoshi Koizumi wrote: On 2005/03/11, at 10:24, Marcus Boerger wrote: Hello moriyoshi or any other XMLer, please verify the --EXPECT-- d

Re: [PHP-DEV] XML Bug #32001

2005-03-10 Thread Moriyoshi Koizumi
On 2005/03/11, at 10:24, Marcus Boerger wrote: Hello moriyoshi or any other XMLer, please verify the --EXPECT-- data in test ext/xml/tests/bug32001.phpt i am quite sure there are several mistakes in it. Excuse me if I'm just missing something, what kind of mistake do you want to address? Moriyosh

  1   2   3   >