Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
I've personally requested this on the bug tracker: https://bugs.php.net/bug.php?id=62315 P.S.: I hope this gets properly tracked to the thread as I read it from the archive and am not subscribed to the list. - Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
Hi,
I did come up with a problem in my server crashing with SIGBUS.
After long testing/tracing found:
https://bugs.php.net/bug.php?id=52752
Which seems to be totally the same! But for different enviroment.
Unfortunately that bug report seems to have only some workaround to
disable mmap(). I have Centos 6 / x86_64, PHP 5.3.3.
As it's OLD and on Feedback state and this is LONG. So i decided to
send this email and also hope that some developer will check that out.
It's not just 32bit, CentoOS5 and old PHP.
test3.php might need couple of runs to get bus error, sometimes
it just runs and most times it crashes and fast. Also the suggested
workaround to disable MMAP seems to work. But what's the performance
loss in that? And disabling it would need recompile and dunno about
getting RedHat to change their PHP to disable MMAP because of this.
Real fix/patch would be nice and really appreciated! :)
Will comment shorter one to that bug, but for the stuff that
interests the developers:
So how's the latest 5.3.19:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1709
1709switch (*YYCURSOR++) {
(gdb) list
1704}
1705
1706
1707ST_IN_SCRIPTING#|// {
1708while (YYCURSOR YYLIMIT) {
1709switch (*YYCURSOR++) {
1710case '\r':
1711if (*YYCURSOR == '\n') {
1712YYCURSOR++;
1713}
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1709
#1 0x00636640 in zendlex (zendlval=0x7fff2476cb90)
at /root/php-5.3.19/Zend/zend_compile.c:4975
#2 0x00620e66 in zendparse ()
at /root/php-5.3.19/Zend/zend_language_parser.c:3285
#3 0x0062bb52 in compile_file (file_handle=0x7fff2476ce80,
type=value optimized out) at Zend/zend_language_scanner.l:364
#4 0x005362d1 in phar_compile_file (file_handle=0x7fff2476ce80,
type=2) at /root/php-5.3.19/ext/phar/phar.c:3394
#5 0x0062b3de in compile_filename (type=2, filename=0x185ac58)
at Zend/zend_language_scanner.l:407
#6 0x0067c63e in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0x7fe9b5916050)
at /root/php-5.3.19/Zend/zend_vm_execute.h:1967
#7 0x00675a30 in execute (op_array=0x184f358)
at /root/php-5.3.19/Zend/zend_vm_execute.h:107
#8 0x0064f86f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.19/Zend/zend.c:1259
#9 0x005fcd67 in php_execute_script (primary_file=0x7fff24770780)
at /root/php-5.3.19/main/main.c:2316
#10 0x006da002 in main (argc=2, argv=0x7fff24770a18)
at /root/php-5.3.19/sapi/cli/php_cli.c:1189
So it's still there and no need to blame my PHP 5.3.3.
So how about PHP 5.4.9?
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1904
1904switch (*YYCURSOR++) {
(gdb) list
1899}
1900
1901
1902ST_IN_SCRIPTING#|// {
1903while (YYCURSOR YYLIMIT) {
1904switch (*YYCURSOR++) {
1905case '\r':
1906if (*YYCURSOR == '\n') {
1907YYCURSOR++;
1908}
(gdb) bt
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1904
#1 0x0063fd90 in zendlex (zendlval=0x7fff4739ebf0)
at /root/php-5.4.9/Zend/zend_compile.c:6707
#2 0x00628ba4 in zendparse ()
at /root/php-5.4.9/Zend/zend_language_parser.c:3430
#3 0x00634d4d in compile_file (file_handle=0x7fff4739ef40,
type=value optimized out) at Zend/zend_language_scanner.l:582
#4 0x00539ae1 in phar_compile_file (file_handle=0x7fff4739ef40,
type=2) at /root/php-5.4.9/ext/phar/phar.c:3388
#5 0x006344ae in compile_filename (type=2, filename=0x7f66ed826d20)
at Zend/zend_language_scanner.l:625
#6 0x006acb6b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0x7f66ed7ea060) at
/root/php-5.4.9/Zend/zend_vm_execute.h:2608
#7 0x006c98a0 in execute (op_array=0x7f66ed81f938)
at /root/php-5.4.9/Zend/zend_vm_execute.h:410
#8 0x006608cd in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.4.9/Zend/zend.c:1309
#9 0x00603e27 in php_execute_script (primary_file=0x7fff473a2680)
at /root/php-5.4.9/main/main.c:2482
#10 0x0070aeac in do_cli (argc=2, argv=0x7fff473a2a88)
at /root/php-5.4.9/sapi/cli/php_cli.c:988
#11 0x0070b608 in main (argc=2, argv=0x7fff473a2a88)
at /root/php-5.4.9/sapi/cli/php_cli.c:1364
Still there.. so how about trunk?
Core was generated
[PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
Hi,
I did come up with a problem in my server crashing with SIGBUS.
After long testing/tracing found:
https://bugs.php.net/bug.php?id=52752
Which seems to be totally the same! But for different enviroment.
Unfortunately that bug report seems to have only some workaround to
disable mmap(). I have Centos 6 / x86_64, PHP 5.3.3.
As it's OLD and on Feedback state and this is LONG. So i decided to
send this email and also hope that some developer will check that out.
It's not just 32bit, CentoOS5 and old PHP.
test3.php might need couple of runs to get bus error, sometimes
it just runs and most times it crashes and fast. Also the suggested
workaround to disable MMAP seems to work. But what's the performance
loss in that? And disabling it would need recompile and dunno about
getting RedHat to change their PHP to disable MMAP because of this.
Real fix/patch would be nice and really appreciated! :)
Will comment shorter one to that bug, but for the stuff that
interests the developers:
So how's the latest 5.3.19:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1709
1709switch (*YYCURSOR++) {
(gdb) list
1704}
1705
1706
1707ST_IN_SCRIPTING#|// {
1708while (YYCURSOR YYLIMIT) {
1709switch (*YYCURSOR++) {
1710case '\r':
1711if (*YYCURSOR == '\n') {
1712YYCURSOR++;
1713}
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1709
#1 0x00636640 in zendlex (zendlval=0x7fff2476cb90)
at /root/php-5.3.19/Zend/zend_compile.c:4975
#2 0x00620e66 in zendparse ()
at /root/php-5.3.19/Zend/zend_language_parser.c:3285
#3 0x0062bb52 in compile_file (file_handle=0x7fff2476ce80,
type=value optimized out) at Zend/zend_language_scanner.l:364
#4 0x005362d1 in phar_compile_file (file_handle=0x7fff2476ce80,
type=2) at /root/php-5.3.19/ext/phar/phar.c:3394
#5 0x0062b3de in compile_filename (type=2, filename=0x185ac58)
at Zend/zend_language_scanner.l:407
#6 0x0067c63e in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0x7fe9b5916050)
at /root/php-5.3.19/Zend/zend_vm_execute.h:1967
#7 0x00675a30 in execute (op_array=0x184f358)
at /root/php-5.3.19/Zend/zend_vm_execute.h:107
#8 0x0064f86f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.19/Zend/zend.c:1259
#9 0x005fcd67 in php_execute_script (primary_file=0x7fff24770780)
at /root/php-5.3.19/main/main.c:2316
#10 0x006da002 in main (argc=2, argv=0x7fff24770a18)
at /root/php-5.3.19/sapi/cli/php_cli.c:1189
So it's still there and no need to blame my PHP 5.3.3.
So how about PHP 5.4.9?
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1904
1904switch (*YYCURSOR++) {
(gdb) list
1899}
1900
1901
1902ST_IN_SCRIPTING#|// {
1903while (YYCURSOR YYLIMIT) {
1904switch (*YYCURSOR++) {
1905case '\r':
1906if (*YYCURSOR == '\n') {
1907YYCURSOR++;
1908}
(gdb) bt
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1904
#1 0x0063fd90 in zendlex (zendlval=0x7fff4739ebf0)
at /root/php-5.4.9/Zend/zend_compile.c:6707
#2 0x00628ba4 in zendparse ()
at /root/php-5.4.9/Zend/zend_language_parser.c:3430
#3 0x00634d4d in compile_file (file_handle=0x7fff4739ef40,
type=value optimized out) at Zend/zend_language_scanner.l:582
#4 0x00539ae1 in phar_compile_file (file_handle=0x7fff4739ef40,
type=2) at /root/php-5.4.9/ext/phar/phar.c:3388
#5 0x006344ae in compile_filename (type=2, filename=0x7f66ed826d20)
at Zend/zend_language_scanner.l:625
#6 0x006acb6b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0x7f66ed7ea060) at
/root/php-5.4.9/Zend/zend_vm_execute.h:2608
#7 0x006c98a0 in execute (op_array=0x7f66ed81f938)
at /root/php-5.4.9/Zend/zend_vm_execute.h:410
#8 0x006608cd in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.4.9/Zend/zend.c:1309
#9 0x00603e27 in php_execute_script (primary_file=0x7fff473a2680)
at /root/php-5.4.9/main/main.c:2482
#10 0x0070aeac in do_cli (argc=2, argv=0x7fff473a2a88)
at /root/php-5.4.9/sapi/cli/php_cli.c:988
#11 0x0070b608 in main (argc=2, argv=0x7fff473a2a88)
at /root/php-5.4.9/sapi/cli/php_cli.c:1364
Still there.. so how about trunk?
Core was generated
[PHP-DEV] The built-in PHP web server is very cool!
Hello, I would like to thank you guys very much for adding the built-in PHP web server to PHP. For the first time I've just deployed a quick standalone app without having to go through the trouble of configuring IIS or any other web server. The installation was easy as ABC. The built-in server was designed for development purposes and is not suitable for production environments but IMO it's great for standalone applications. Keep up the good work and improve the features of the server when necessary. __ Raymond
Re: [PHP-DEV] The built-in PHP web server is very cool!
On Wed, Dec 19, 2012 at 10:05 AM, Raymond Irving xwis...@gmail.com wrote: Hello, I would like to thank you guys very much for adding the built-in PHP web server to PHP. For the first time I've just deployed a quick standalone app without having to go through the trouble of configuring IIS or any other web server. The installation was easy as ABC. The built-in server was designed for development purposes and is not suitable for production environments but IMO it's great for standalone applications. Keep up the good work and improve the features of the server when necessary. __ Raymond Even for standalone apps it's not a great idea to use it.
Re: [PHP-DEV] The built-in PHP web server is very cool!
Hi William, Why not? On Wed, Dec 19, 2012 at 11:07 AM, William Betts william.be...@gmail.comwrote: On Wed, Dec 19, 2012 at 10:05 AM, Raymond Irving xwis...@gmail.com wrote: Hello, I would like to thank you guys very much for adding the built-in PHP web server to PHP. For the first time I've just deployed a quick standalone app without having to go through the trouble of configuring IIS or any other web server. The installation was easy as ABC. The built-in server was designed for development purposes and is not suitable for production environments but IMO it's great for standalone applications. Keep up the good work and improve the features of the server when necessary. __ Raymond Even for standalone apps it's not a great idea to use it.
Re: [PHP-DEV] The built-in PHP web server is very cool!
2012/12/19 Raymond Irving xwis...@gmail.com: Hi William, Why not? Thank you for the kind words Raymond (which should be addressed to Moriyoshi Koizumi), but as mentioned on: http://php.net/manual/en/features.commandline.webserver.php: * It has never been created for anything else than development purpose only. * It also cannot handle more than one request at a time, meaning that if your application has several assets (images, js files, css files,...) all of them will be downloaded sequentially. Situation that is even worse if you have more than one concurrent user. * When it starts, it mentions: Development Server started, please, let me kindly emphasize the first word once more. Criticisms have been raised about including that feature to the core of PHP for the exact reason that it might be used as a simpler alternative to real web servers. To avoid that, some stress has been put on documentation to insist on not using it for anything else than development. There is also lot of programs bundling PHP, a web server and a database server that are easy to use and configure. Please, don't let room to bad practices which might end up damaging PHP's reputation. @Moriyoshi: Maybe you have more arguments to add? Maybe we should list the reasons not to use it on anything else than development on http://php.net/manual/en/features.commandline.webserver.php? Regards, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Added a test case for DateTimePoint.: ext/date/tests/date_time_point.phpt
hi Derick, On Wed, Dec 19, 2012 at 6:53 PM, Derick Rethans der...@php.net wrote: Commit:7c74531e884aaa0a0bf6db76adb0e203cdb81c02 Author:Derick Rethans git...@derickrethans.nl Mon, 17 Dec 2012 16:35:52 + Parents: d4acb579df4c78acaaff3e90698277e62aac Branches: immutable-date Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=7c74531e884aaa0a0bf6db76adb0e203cdb81c02 Log: Added a test case for DateTimePoint. I think the way you deal with date is not correct. there were many voices saying that DateTimePoint was not a good name. Given that ext/date is enabled by default and standard, you should go through a RFC for such things, keeping in mind that there was no real concensus on the name. This comment should apply to anything in core and standard functions. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Added a test case for DateTimePoint.: ext/date/tests/date_time_point.phpt
On Wed, 19 Dec 2012, Pierre Joye wrote: hi Derick, On Wed, Dec 19, 2012 at 6:53 PM, Derick Rethans der...@php.net wrote: Commit:7c74531e884aaa0a0bf6db76adb0e203cdb81c02 Author:Derick Rethans git...@derickrethans.nl Mon, 17 Dec 2012 16:35:52 + Parents: d4acb579df4c78acaaff3e90698277e62aac Branches: immutable-date Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=7c74531e884aaa0a0bf6db76adb0e203cdb81c02 Log: Added a test case for DateTimePoint. I think the way you deal with date is not correct. there were many voices saying that DateTimePoint was not a good name. That's why I have changed it to DateTimeImmutable. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete traits redesign for 5.5
On 12/19/2012 01:39 AM, Dmitry Stogov wrote: Hi, opcode caches support is one of the problem we have with current implementation. 5.4.10 seems just can't work with any cache at all. Of course, I'll care about it, and may give suggestions for necessary APC changes. Do you have an example use of traits that doesn't work with APC? I actually thought we had gotten to all of the edge cases here. At least all the trait tests pass currently with APC. But yes, it was a pain, so some cleanup would be good. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
Hi! I did come up with a problem in my server crashing with SIGBUS. After long testing/tracing found: https://bugs.php.net/bug.php?id=52752 Just tried to reproduce it on Centos 6.2 install (without APC), works just fine for me. I suspect it's some APC issue, does it reproduce for you without APC loaded? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
On 12/19/2012 03:27 PM, Stas Malyshev wrote: Hi! I did come up with a problem in my server crashing with SIGBUS. After long testing/tracing found: https://bugs.php.net/bug.php?id=52752 Just tried to reproduce it on Centos 6.2 install (without APC), works just fine for me. I suspect it's some APC issue, does it reproduce for you without APC loaded? It doesn't seem APC-related since it is happening on the first pass. It is unusual for a non-cached script to cause problems in APC, but it is of course still possible. A test without APC would be helpful to narrow it down. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Rejected: sajith rejected by bjori
Nuked sajith -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crashes in lex_scan at Zend/zend_language_scanner.c / BUG #52752
On 19.12.2012 22:27, Stas Malyshev wrote:
https://bugs.php.net/bug.php?id=52752
Just tried to reproduce it on Centos 6.2 install (without APC), works
just fine for me. I suspect it's some APC issue, does it reproduce for
you without APC loaded?
Yes, as I mentioned in previous message and in the comments of that bug.
I'll hilight the relevant backtrace in this message.
Did you tried to run it couple of times? In my tests in one machine
it seemed sometimes run without any problems but then ctrl-c and running
again got the sigbus.
CopyPaste from bugs.php.net:
5.3.19:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1709
1709switch (*YYCURSOR++) {
(gdb) list
1704}
1705
1706
1707ST_IN_SCRIPTING#|// {
1708while (YYCURSOR YYLIMIT) {
1709switch (*YYCURSOR++) {
1710case '\r':
1711if (*YYCURSOR == '\n') {
1712YYCURSOR++;
1713}
#0 lex_scan (zendlval=value optimized out)
at Zend/zend_language_scanner.l:1709
#1 0x00636640 in zendlex (zendlval=0x7fff2476cb90)
at /root/php-5.3.19/Zend/zend_compile.c:4975
#2 0x00620e66 in zendparse ()
at /root/php-5.3.19/Zend/zend_language_parser.c:3285
#3 0x0062bb52 in compile_file (file_handle=0x7fff2476ce80,
type=value optimized out) at Zend/zend_language_scanner.l:364
#4 0x005362d1 in phar_compile_file (file_handle=0x7fff2476ce80,
type=2) at /root/php-5.3.19/ext/phar/phar.c:3394
#5 0x0062b3de in compile_filename (type=2, filename=0x185ac58)
at Zend/zend_language_scanner.l:407
#6 0x0067c63e in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0x7fe9b5916050)
at /root/php-5.3.19/Zend/zend_vm_execute.h:1967
#7 0x00675a30 in execute (op_array=0x184f358)
at /root/php-5.3.19/Zend/zend_vm_execute.h:107
#8 0x0064f86f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.19/Zend/zend.c:1259
#9 0x005fcd67 in php_execute_script (primary_file=0x7fff24770780)
at /root/php-5.3.19/main/main.c:2316
#10 0x006da002 in main (argc=2, argv=0x7fff24770a18)
at /root/php-5.3.19/sapi/cli/php_cli.c:1189
Test file was also in that bugs comments, which i modified a little
to get it to use version that i did compile.
# cat test3.php
?php
if ($argv[1] 0) {
while ($argv[1]--) file_put_contents('test.tpl', ?php
#.str_repeat('A', mt_rand(4000, 5000)). ?\n, LOCK_EX);
} else {
$p2 = popen(sapi/cli/php test3.php 100, r);
while (1) include 'test.tpl';
}
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_parse_parameters() improvements
On Wed, Jul 18, 2012 at 11:05 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: Some deficiencies in zpp have been constrai ning the implementation of common scenarios such as 'allow integer or NULL'* or the more general 'allow different types for an argument'**. So I propose the changes in this branch: https://github.com/cataphract/php-src/compare/zpp_improv What's the state of this? Nikita
Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
On 12/18/12 7:44 AM, Leigh wrote:
On 18 December 2012 13:24, Stefan Neufeind neufe...@php.net wrote:
Since we already have functionality for replacing with arrays in place,
I wondered if giving it one string to replace and then an array to
choose the replacement from (rotating) would be an option. Currently
that's unsupported (either two strings or two arrays).
It's certainly possible to implement, but personally it feels like odd
behaviour. I don't know what other people think about it.
I think you could use a callback-function but would need to add quite a
few more lines to initialise your array first, do a next() on the
array inside the callback-function and (how would you pass it that
array?) and still would have to handle starting from beginning of the
array again once you reach the end etc.
You pass the array using use. You could do it something like this:
$replacements = array(
'one', 'two', 'three'
);
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements) {
$current = current($replacements);
next($replacements) || reset($replacements);
return $current;
},
'word word word word word'
);
var_dump($result);
Output:
string(21) one two three one two
You could likely simplify the code even further using an infinite iterator:
http://us1.php.net/infiniteiterator
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
return $replacements-next();
},
'word word word word word'
);
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The built-in PHP web server is very cool!
Hi Patrick, Thanks for the feedback. I see your point and share some of your concerns. * It also cannot handle more than one request at a time...* In my case a standalone web app will only be deployed on a single computer and will only be used by one user at a time, so concurrency should not be a problem. No other user will be able to access the application from the network. These are basically single user web-desktop applications. On Wed, Dec 19, 2012 at 12:33 PM, Patrick ALLAERT patrickalla...@php.netwrote: 2012/12/19 Raymond Irving xwis...@gmail.com: Hi William, Why not? Thank you for the kind words Raymond (which should be addressed to Moriyoshi Koizumi), but as mentioned on: http://php.net/manual/en/features.commandline.webserver.php: * It has never been created for anything else than development purpose only. * It also cannot handle more than one request at a time, meaning that if your application has several assets (images, js files, css files,...) all of them will be downloaded sequentially. Situation that is even worse if you have more than one concurrent user. * When it starts, it mentions: Development Server started, please, let me kindly emphasize the first word once more. Criticisms have been raised about including that feature to the core of PHP for the exact reason that it might be used as a simpler alternative to real web servers. To avoid that, some stress has been put on documentation to insist on not using it for anything else than development. There is also lot of programs bundling PHP, a web server and a database server that are easy to use and configure. Please, don't let room to bad practices which might end up damaging PHP's reputation. @Moriyoshi: Maybe you have more arguments to add? Maybe we should list the reasons not to use it on anything else than development on http://php.net/manual/en/features.commandline.webserver.php ? Regards, Patrick
Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
On 12/19/2012 03:18 PM, Larry Garfield wrote:
You could likely simplify the code even further using an infinite iterator:
http://us1.php.net/infiniteiterator
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
return $replacements-next();
},
'word word word word word'
);
--Larry Garfield
What am I missing that causes the first call to
$replacements_iterator-current() to return NULL
unless the iterator is rewound before use?
Chris
--
?php
$replacements = array(
'one', 'two', 'three'
);
$replacements_iterator = new InfiniteIterator(new ArrayIterator($replacements));
$replacements_iterator-rewind(); // why is the rewind needed?
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator-current();
$replacements_iterator-next();
return $r;
},
'word word word word word'
);
var_dump($result);
// Outputs:
//string(21) one two three one two
// Without the call to $replacements_iterator-rewind(), the output is:
//string(18) two three one two
?
--
christopher.jo...@oracle.com http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Added a test case for DateTimePoint.: ext/date/tests/date_time_point.phpt
hi Derick, On Wed, Dec 19, 2012 at 8:05 PM, Derick Rethans der...@php.net wrote: On Wed, 19 Dec 2012, Pierre Joye wrote: hi Derick, On Wed, Dec 19, 2012 at 6:53 PM, Derick Rethans der...@php.net wrote: Commit:7c74531e884aaa0a0bf6db76adb0e203cdb81c02 Author:Derick Rethans git...@derickrethans.nl Mon, 17 Dec 2012 16:35:52 + Parents: d4acb579df4c78acaaff3e90698277e62aac Branches: immutable-date Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=7c74531e884aaa0a0bf6db76adb0e203cdb81c02 Log: Added a test case for DateTimePoint. I think the way you deal with date is not correct. there were many voices saying that DateTimePoint was not a good name. That's why I have changed it to DateTimeImmutable. Right, however my point remains. There was no concensus and a RFC would make a clear choice. Easy, simple, open. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete traits redesign for 5.5
Hi Rasmus, I'm not sure about APC, I saw the problem in ZendOptimizerPlus with php-5.4.10. O+ crashes (or corrupts memory and crashes on following requests) on each trait usage. The problem that PHP tries to deallocate names of methods defined in traits, but O+ keeps them in SHM. I believe APC must have the same problem. Thanks. Dmitry. On Wed, Dec 19, 2012 at 11:09 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 12/19/2012 01:39 AM, Dmitry Stogov wrote: Hi, opcode caches support is one of the problem we have with current implementation. 5.4.10 seems just can't work with any cache at all. Of course, I'll care about it, and may give suggestions for necessary APC changes. Do you have an example use of traits that doesn't work with APC? I actually thought we had gotten to all of the edge cases here. At least all the trait tests pass currently with APC. But yes, it was a pain, so some cleanup would be good. -Rasmus
