Re: [PHP-DEV] Naming issues, solutions
Hey: On Sun, Aug 24, 2014 at 8:30 PM, Pierre Joye pierre@gmail.com wrote: Hi, Nikita, Xinchen and I have sit down together this morning to solve a couple of naming issues, those having caused some flames, trolls and FUDs in the last couple of days. The good news is we have found a consensus that solves our concerns, consistency and reduce the amount of changes in existing code. Please not that this mail is not my personal taste or wishes, but the results of a refreshing, constructive and good discussions with Xinchen and Nikita earlier this morning. Summary: zend_uint int32_t zend_size_tsize_t zend_int_t zend_long IS_INT IS_LONG Z_IVAL Z_LVAL Z_STRSIZE Z_STRLEN zend_str_* zend_string_* STR_* macros droped Details: We have a header available by default to define c9* stdint, see main/php_stdint.h. This header ensures consistency accross platforms and that the size of each type is correct. It is important to keep that in mind while reading the rest of this mail. * zend_uint zend_uint is used exclusevely in the engine (maybe some debugger or engine related extensions) and has been around for a while. We like to drop it and use int32_t instead anywhere where zend_uint is used. Using int32_t is good because this will ensure that we use the correct type even on ILP64 - zend_uint would currently totally blow up on those systems. *zend_size_t Given that size_t is a standard type, adding zend_size_t makes little sense. * zend_int_t, zend_long, IS_INT/IS_LONG One of my main concerns is consistency between APIs and macros names and the underlying types. A solution to this problem was quite obvious (only not on Friday ;). zend_int_t will be renamed to zend_long, IS_INT and Z_IVAL will renamed to their old names, IS_LONG and Z_LVAL, respectively. * Strings First change, Z_STRSIZE will be renamed to Z_STRLEN (old name). We also like to drop STR_ macros and rely directly on the zend_string_* APIs. While doing at it the zend_string APIs will be prefix zend_string and not zend_str_* as it is now, for the same reason: During the NG works and the ports of many extensions, numerous bugs appear due to bad usage of STR_* macros with either char* or other char/string related types. Making the name more obvious will help. PS: IRC log available if anyone likes to double check it, #php.pecl thanks. I am glad we have reach a agreement here. actually to me, the naming issue has blocked me to start porting work on my own exts, so if no objections, I'd like to see it settled down and commit to trunk asap :) thanks Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
Hey: On Thu, Aug 21, 2014 at 11:30 PM, Derick Rethans der...@php.net wrote: On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics Thoughts and questions are appreciated. Thanks! snip And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that Backwards Compatibility is not an issue with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be oh we have a major new version so we can break all the things™. There are two main types of breaking Backwards Compatibility: 1. The obvious case where running things trough ``php -l`` instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple default cases, it's a fricking bug fix too). 2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the Uniform Variable Syntax, that I already `wrote about`_, the current discussion on `Binary String Comparison`_, and now changing the `behaviour`_ on and in a subtle way. These changes are *not okay*, because they are nearly impossible to test for. Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the ``$`` in front of variables to ``£`` is a better change, as it's *immediately* apparent that stuff changed. And you can't get away with But Symfony and ZendFramework don't use this either, as there is so much code out there I am totally agree with Derick here. We should avoid to change such basic behaves.. thanks As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science purity reasons to make things better have little to no meaning for PHP, as it's clearly not designed in the first place. Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. **Don't be Evil** cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hey: I find a problem while I was trying play with the patch Generating phar.php Generating phar.phar Fatal error: Out of memory (allocated 786432) at /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 (tried to allocate 34359738400 bytes) in /home/huixinchen/opensource/github/php-src/ext/phar/phar.php on line 163 make: *** [ext/phar/phar.phar] Error 255 make: *** Waiting for unfinished jobs is this a knew issue? thanks On Tue, Aug 19, 2014 at 2:36 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Andi, We already discussed most of semantic changes introduced in AST patch. Most of them came from another approved RFC https://wiki.php.net/rfc/uniform_variable_syntax Thanks. Dmitry. On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans a...@zend.com wrote: Hi Nikita, I reviewed the AST RFC on my way to vote but there was something that wasn’t clear to me. This patch introduces some semantic/behavioral changes in addition to the AST. Are these as a side-effect of how AST was implemented? Or are they unrelated to the AST patch? I think some of them make sense but I’m having a bit of a hard time separating out the benefits of the AST (which I really like) and making other changes to semantics w/o really understanding if they are side-effects and we have no choice vs. we’re trying to solve for two separate items in one RFC. Any BC breaks here we think could bite us? Any insight would be much appreciated. Thanks! Andi On Aug 18, 2014, at 9:41 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I've opened the vote on the Abstract Syntax Tree RFC: https://wiki.php.net/rfc/abstract_syntax_tree#vote Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hey: the problem came from zend_ast_size for 0 children node.. backtrace: Program terminated with signal 6, Aborted. #0 0x0034dc030285 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0034dc030285 in raise () from /lib64/libc.so.6 #1 0x0034dc031d30 in abort () from /lib64/libc.so.6 #2 0x009d271c in _zend_mm_alloc_int (heap=0x82fff40, size=34359738400, __zend_filename=0xfc5c78 /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h, __zend_lineno=69, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2003 #3 0x009d4354 in _emalloc (size=34359738400, __zend_filename=0xfc5c78 /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h, __zend_lineno=69, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2442 #4 0x00a42c05 in zend_arena_alloc (arena_ptr=0x135e698, size=34359738376) at /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 #5 0x00a42b0e in zend_ast_alloc (size=34359738376) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:27 #6 0x00a42dcb in zend_ast_create_from_va_list (kind=1, attr=7, va=0x7fff2be64550) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89 #7 0x00a4303e in zend_ast_create_ex (kind=1, attr=7) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:116 #8 0x009aa0a3 in zendparse () at /home/huixinchen/opensource/github/php-src/Zend/zend_language_parser.y:551 #9 0x009aed81 in compile_file (file_handle=0x7fff2be68850, type=8) at Zend/zend_language_scanner.l:586 #10 0x00784de6 in phar_compile_file (file_handle=0x7fff2be68850, type=8) at /home/huixinchen/opensource/github/php-src/ext/phar/phar.c:3358 #11 0x00a0bab2 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixinchen/opensource/github/php-src/Zend/zend.c:1301 #12 0x0097529b in php_execute_script (primary_file=0x7fff2be68850) at /home/huixinchen/opensource/github/php-src/main/main.c:2564 #13 0x00ac44b1 in do_cli (argc=31, argv=0x82ff680) at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:980 #14 0x00ac55de in main (argc=31, argv=0x82ff680) at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:1358 (gdb) f 6 #6 0x00a42dcb in zend_ast_create_from_va_list (kind=1, attr=7, va=0x7fff2be64550) at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89 89 zend_ast *ast = zend_ast_alloc(zend_ast_size(children) TSRMLS_CC); (gdb) p children $1 = 0 thanks On Tue, Aug 19, 2014 at 5:12 PM, Laruence larue...@php.net wrote: Hey: I find a problem while I was trying play with the patch Generating phar.php Generating phar.phar Fatal error: Out of memory (allocated 786432) at /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 (tried to allocate 34359738400 bytes) in /home/huixinchen/opensource/github/php-src/ext/phar/phar.php on line 163 make: *** [ext/phar/phar.phar] Error 255 make: *** Waiting for unfinished jobs is this a knew issue? thanks On Tue, Aug 19, 2014 at 2:36 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Andi, We already discussed most of semantic changes introduced in AST patch. Most of them came from another approved RFC https://wiki.php.net/rfc/uniform_variable_syntax Thanks. Dmitry. On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans a...@zend.com wrote: Hi Nikita, I reviewed the AST RFC on my way to vote but there was something that wasn’t clear to me. This patch introduces some semantic/behavioral changes in addition to the AST. Are these as a side-effect of how AST was implemented? Or are they unrelated to the AST patch? I think some of them make sense but I’m having a bit of a hard time separating out the benefits of the AST (which I really like) and making other changes to semantics w/o really understanding if they are side-effects and we have no choice vs. we’re trying to solve for two separate items in one RFC. Any BC breaks here we think could bite us? Any insight would be much appreciated. Thanks! Andi On Aug 18, 2014, at 9:41 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I've opened the vote on the Abstract Syntax Tree RFC: https://wiki.php.net/rfc/abstract_syntax_tree#vote Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
Hey:
a fix could be:
diff --git a/Zend/zend_ast.c b/Zend/zend_ast.c
index eb35a51..f738e34 100644
--- a/Zend/zend_ast.c
+++ b/Zend/zend_ast.c
@@ -33,11 +33,11 @@ static inline void *zend_ast_realloc(void *old,
size_t old_size, size_t new_size
return new;
}
-size_t zend_ast_size(zend_uint children) {
+size_t zend_ast_size(int children) {
return sizeof(zend_ast) + sizeof(zend_ast *) * (children - 1);
}
-size_t zend_ast_list_size(zend_uint children) {
+size_t zend_ast_list_size(int children) {
return sizeof(zend_ast_list) + sizeof(zend_ast *) * (children - 1);
}
my compiler must take (children -1) as a unsigned
thanks
On Tue, Aug 19, 2014 at 5:21 PM, Laruence larue...@php.net wrote:
Hey:
the problem came from zend_ast_size for 0 children node..
backtrace:
Program terminated with signal 6, Aborted.
#0 0x0034dc030285 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0034dc030285 in raise () from /lib64/libc.so.6
#1 0x0034dc031d30 in abort () from /lib64/libc.so.6
#2 0x009d271c in _zend_mm_alloc_int (heap=0x82fff40,
size=34359738400,
__zend_filename=0xfc5c78
/home/huixinchen/opensource/github/php-src/Zend/zend_arena.h,
__zend_lineno=69,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2003
#3 0x009d4354 in _emalloc (size=34359738400,
__zend_filename=0xfc5c78
/home/huixinchen/opensource/github/php-src/Zend/zend_arena.h,
__zend_lineno=69,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /home/huixinchen/opensource/github/php-src/Zend/zend_alloc.c:2442
#4 0x00a42c05 in zend_arena_alloc (arena_ptr=0x135e698,
size=34359738376)
at /home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69
#5 0x00a42b0e in zend_ast_alloc (size=34359738376)
at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:27
#6 0x00a42dcb in zend_ast_create_from_va_list (kind=1,
attr=7, va=0x7fff2be64550)
at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89
#7 0x00a4303e in zend_ast_create_ex (kind=1, attr=7)
at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:116
#8 0x009aa0a3 in zendparse () at
/home/huixinchen/opensource/github/php-src/Zend/zend_language_parser.y:551
#9 0x009aed81 in compile_file (file_handle=0x7fff2be68850,
type=8) at Zend/zend_language_scanner.l:586
#10 0x00784de6 in phar_compile_file (file_handle=0x7fff2be68850,
type=8)
at /home/huixinchen/opensource/github/php-src/ext/phar/phar.c:3358
#11 0x00a0bab2 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/huixinchen/opensource/github/php-src/Zend/zend.c:1301
#12 0x0097529b in php_execute_script (primary_file=0x7fff2be68850)
at /home/huixinchen/opensource/github/php-src/main/main.c:2564
#13 0x00ac44b1 in do_cli (argc=31, argv=0x82ff680)
at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:980
#14 0x00ac55de in main (argc=31, argv=0x82ff680)
at /home/huixinchen/opensource/github/php-src/sapi/cli/php_cli.c:1358
(gdb) f 6
#6 0x00a42dcb in zend_ast_create_from_va_list (kind=1,
attr=7, va=0x7fff2be64550)
at /home/huixinchen/opensource/github/php-src/Zend/zend_ast.c:89
89 zend_ast *ast = zend_ast_alloc(zend_ast_size(children) TSRMLS_CC);
(gdb) p children
$1 = 0
thanks
On Tue, Aug 19, 2014 at 5:12 PM, Laruence larue...@php.net wrote:
Hey:
I find a problem while I was trying play with the patch
Generating phar.php
Generating phar.phar
Fatal error: Out of memory (allocated 786432) at
/home/huixinchen/opensource/github/php-src/Zend/zend_arena.h:69 (tried
to allocate 34359738400 bytes) in
/home/huixinchen/opensource/github/php-src/ext/phar/phar.php on line
163
make: *** [ext/phar/phar.phar] Error 255
make: *** Waiting for unfinished jobs
is this a knew issue?
thanks
On Tue, Aug 19, 2014 at 2:36 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Andi,
We already discussed most of semantic changes introduced in AST patch.
Most of them came from another approved RFC
https://wiki.php.net/rfc/uniform_variable_syntax
Thanks. Dmitry.
On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans a...@zend.com wrote:
Hi Nikita,
I reviewed the AST RFC on my way to vote but there was something that
wasn’t clear to me.
This patch introduces some semantic/behavioral changes in addition to the
AST.
Are these as a side-effect of how AST was implemented? Or are they
unrelated to the AST patch?
I think some of them make sense but I’m having a bit of a hard time
separating out the benefits of the AST (which I really like) and making
other changes to semantics w/o really understanding if they are
side-effects and we have no choice vs. we’re trying to solve for two
separate items in one RFC.
Any BC breaks here we think could bite us?
Any insight would be much
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
Hey: On Tue, Aug 19, 2014 at 10:10 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, Yesterday we discussed with Nikta the failure of ext/standard/tests/http/bug60570.phpt. It was in context of AST patch, but the failure is not related to AST at all. It's just a bad test that makes wrong assumption. Resource leaks can't be caught using get_memory_usage(). To have a robust way to detect resource leaks I propose a new function - get_resources() that returns an array of all registered resources or an array of registered resources of particular type. See patch: https://gist.github.com/dstogov/f96c04f5979e726909ab I'm not sure if such small change needs RFC. Thoughts? I think it's okey to have a such function. we have get_defined_functions/constants/vars thanks Thanks. Dmitry. -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
Hey: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics I'd like don't change the works behavior. make it act the similar as C does. thanks Thoughts and questions are appreciated. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PowerPC64 patchs
Hey: There are some PRs for supports of PowerPC64 https://github.com/php/php-src/pull/734 https://github.com/php/php-src/pull/735 https://github.com/php/php-src/pull/736 https://github.com/php/php-src/pull/737 Anyone can review them? or, I will commit the patches by tomorrow.. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PowerPC64 patchs
Hey: thanks very much for testing this. then seems I should not commit this for now. thanks On Mon, Aug 18, 2014 at 5:33 PM, Remi Collet r...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/08/2014 11:21, Stas Malyshev a écrit : BTW, it'd be nice to figure out why we have 6 fails there :) I already spent a lot of time fixing various non-intel failed tests... 3 related to date can be ignored (because of fedora / red hat system-tzdata patch, and tzdata is only 2014e in rhel, 2014f in php) 3 related to and operators are caused by different behavior of the C operator on ppc processor. Don't know what is the better way to have them fixed... Do we want the operator to behave the same way on all arch. or does it seems acceptable to keep arch specific behavior... ? Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPxyIQACgkQYUppBSnxahjGpQCfX7aMZtqTGs6dlqxH/YLRnHq/ jO0An2mzbWU8/CxcN/uqB/Bz3SsxKBha =EKAg -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed version check: ext/mysqli/mysqli.c
Hey: sorry for top reply: for people who didn't know the context: we were talking about remove all #if PHP_MAJOR_VERSION = ?? in exts which means, remove all old version supports in master.. what do you think? thanks On Fri, Aug 15, 2014 at 11:28 PM, Pierre Joye pierre@gmail.com wrote: adding mysql@ to the list and move to internals, we should do that for other parts as well but extensions being actively maintained in pecl too (while they will most likely have a separate branche for 7+ anyway. On Fri, Aug 15, 2014 at 5:05 PM, Laruence larue...@php.net wrote: Hey: On Fri, Aug 15, 2014 at 9:48 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 15, 2014 at 12:21 PM, Xinchen Hui larue...@php.net wrote: Commit:7ace092abfec31749da230405a7298d9b5789f43 Author:Xinchen Hui larue...@php.net Fri, 15 Aug 2014 18:21:23 +0800 Parents: 29893a88e7cdf93f9ce80ce7eaecffb3ef5e30c9 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=7ace092abfec31749da230405a7298d9b5789f43 Log: Fixed version check Changed paths: M ext/mysqli/mysqli.c Diff: diff --git a/ext/mysqli/mysqli.c b/ext/mysqli/mysqli.c index 43d471d..9374737 100644 --- a/ext/mysqli/mysqli.c +++ b/ext/mysqli/mysqli.c @@ -585,7 +585,7 @@ PHP_MINIT_FUNCTION(mysqli) mysqli_object_handlers.write_property = mysqli_write_property; mysqli_object_handlers.get_property_ptr_ptr = std_hnd-get_property_ptr_ptr; mysqli_object_handlers.has_property = mysqli_object_has_property; -#if PHP_MAJOR_VERSION == 5 PHP_MINOR_VERSION = 3 +#if PHP_VERSION_ID = 53000 mysqli_object_handlers.get_debug_info = mysqli_object_get_debug_info; #endif memcpy(mysqli_object_driver_handlers, mysqli_object_handlers, sizeof(zend_object_handlers)); Given the amount of changes in the extensions I wonder why we even keep this kind of things in master. Could we not simply clean that up? personally, I also want to do that. but maybe the maintainer of the ext want to keep it. thanks Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- Laruence Xinchen Hui http://www.laruence.com/ -- Pierre @pierrejoye | http://www.libgd.org -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHPNG crashes when using composer
Hey: On Mon, Aug 11, 2014 at 10:07 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Le 01/08/2014 13:58, Pascal Chevrel a écrit : Hi Another bug I found: https://bugs.php.net/bug.php?id=67735 When running composer update on a project I participate in (https://github.com/framasoft/framadate), PHPNG crashes. Regards are you able to get a backtrace? if yes, please paste the backtrace as a comment in that bug entry it will give us a useful help :) thanks Pascal Regarding this bug, can somebody answer my question as to whom I should send the backtrace? Thanks Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reporting bugs for phpng
On Fri, Aug 1, 2014 at 12:34 AM, Pascal Chevrel pascal.chev...@free.fr wrote: Le 31/07/2014 16:23, Laruence a écrit : Hey: On Thu, Jul 31, 2014 at 8:29 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Le 26/07/2014 04:42, Laruence a écrit : Hey: On Fri, Jul 25, 2014 at 9:14 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Hi, I tried the .deb package for phpng that Zend provides since yesterday (thanks for that!) and I hit a memory consumption issue with the first of my scripts I tried: PHPNG: Memory peak: 62914560 (55.97MB) Elapsed time (s): 0.3383 PHP 5.5: Memory peak: 1835008 (1.64MB) Elapsed time (s): 0.0717 How/where can I make a bug report about it? Is https://bugs.php.net/ ok for PHPNG bugs? PHPNG is not listed in bugs.php.net yet. but as it's a branch of PHP , I think it's okey to report it there, and note it's PHPNG in the comment. for now. thanks Hi, I opened this bug: https://bugs.php.net/bug.php?id=67725 I put a testcase triggering the memory leak in a github repo referenced in the bug. I am afraid this is not a bug. it's due to our new immutable array implementation. all these langs map array are constant array, such it will be treat as immutable array, which means it will not be released untill the request shutdown. (which will bring significant performance improvement for saving array construct/destruct while use with opcache) I suggest you to increase the memory_limit as a workaround .. Anyway, Dmitry, what do you think? maybe something like interned_string_size? Hi, The problem is that the more arrays I load, the more memory PHPNG consumes while current versions of PHP have that value mostly stable. I have with PHPNG a scalability issue I don't have with regular PHP. If tomorrow I increase the number of languages I support in my app from 70 to 200 (which is my long term goal btw), I would probably need to set memory_limit to 700MB which seems honestly crazy when PHP 5.x needs 8MB for the same script to run at the same speed. As an end user, I think it's a bug not a feature, I hope you understand my point of view :). I understand your point, and the problem, but the thing here is, do you really needs loads all langs map arrays in a single request(as I understand you only need one per request, right?) Also, people on shared hosting can't change the memory_limit value, it doesn't sound like a change that is good for PHP in shared hosting environment which is a large part of PHP success. You mention that it is beneficial when OPCache is activated, but it isn't activated by default, so the theoretical gain would only work for people that can activate it, right? Or does it mean that OPCache would be activated by default in PHP 7? I will suggest to enable it by default in NG. Is there no way to release the memory programmatically before the request ends? Shouldn't explicitely using unset() on the array at the end of each iteration indicate to the engine that I don't just want to destroy the array reference but also get the memory back? That sounds like a very significant change in how PHP behaves today with arrays, doesn't it? PHPNG is promoted as a big speed optimization that wouldn't impact userland code, well, in my case it does and very significantly if parts of my app crash or use 20 or 30 times more memory than before for a 5% speed gain, it's not a win. If there is a way to force PHP to unload that data from memory and basically behave like PHP 5.x it could at least be in PHP 7 upgrade release notes for people like me that build stuff on today's PHP strengths. hmm, I will definitely ask dmitry 's idea.. thanks Thanks, Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reporting bugs for phpng
Hey: On Thu, Jul 31, 2014 at 8:29 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Le 26/07/2014 04:42, Laruence a écrit : Hey: On Fri, Jul 25, 2014 at 9:14 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Hi, I tried the .deb package for phpng that Zend provides since yesterday (thanks for that!) and I hit a memory consumption issue with the first of my scripts I tried: PHPNG: Memory peak: 62914560 (55.97MB) Elapsed time (s): 0.3383 PHP 5.5: Memory peak: 1835008 (1.64MB) Elapsed time (s): 0.0717 How/where can I make a bug report about it? Is https://bugs.php.net/ ok for PHPNG bugs? PHPNG is not listed in bugs.php.net yet. but as it's a branch of PHP , I think it's okey to report it there, and note it's PHPNG in the comment. for now. thanks Hi, I opened this bug: https://bugs.php.net/bug.php?id=67725 I put a testcase triggering the memory leak in a github repo referenced in the bug. I am afraid this is not a bug. it's due to our new immutable array implementation. all these langs map array are constant array, such it will be treat as immutable array, which means it will not be released untill the request shutdown. (which will bring significant performance improvement for saving array construct/destruct while use with opcache) I suggest you to increase the memory_limit as a workaround .. Anyway, Dmitry, what do you think? maybe something like interned_string_size? thanks Regards Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] About PHP NG document lacking argument
Hey: First of all, I don't want to make *that* thead longer... as you can see, some devers says critically phpng is lacking of document, and they make that as the main reason for them to against phpng. I have to say, in my opinion it's totally ridiculous. 1. how many devers in here really knows zend engine? how many tried to know it? I assume a little, as you can see, only a few activate zend engine maintainers now. dmitry is the most experience one. 2. does PHP really has had a good API document? no, when I first tried to write a extension, I found no documents, or they was far beyond outdate, I event don't know how config.m4 works.. I learn PHP by reading the codes, and the example under ext/* 3. is document really important for PHPng? I don't think so, PHP can always read the codes, PHP is opensource , it is not *MS* who need document to tell people what it did in dark. 4. is PHPng API became more ugly? or harder to maintainable? I feel really bad to see somebody said such things... first of all. ugly, maintainable. it is too too subjective, and to be honest, it's obviously biased attitude. second, I , the main author of PHPNG, and Nikita, Dmitry, are the most activate internal contributors now. so you are saying we are writing ugly codes? I really can not agree with that. actually, the zend_hash API become more clear, and beatifuy than before. maintainable? who is the main force to maintain the PHP internal now? yes, the authors of PHPNG.. I think I have the more rights to say whether it is more maintainer able or not. and it's become more maintainable, because of more clean API and more reasonable logics. 5. are we going to write docs? yes, for people, who in love with PHP, who want to make PHP extensions, we are glad to write some APIs (which will be enough in a dever eye). actually we already doing it: https://wiki.php.net/phpng-upgrading 6. is PHPng really faster? yes, from my own test, it get more than 80% qps improvement in wordpress than php-5.6 . for those big PHP users, that means they can save lots of money. I see no reason to not have such a great change. anyone who tried to block such a amazing feature merge into PHP, is doing crime for PHP. I am not a native english speaker, so maybe I confused you in some words , sorry for that. I really hope the people in this group, the people who loves PHP, the people who want PHP become more popular here. stop less reasonable arguing, let's together to make this biggest change merge into PHP, make PHP users more easy life.. If you think we need write doc, let us write it. If you think we need more clean APIs? please tell me what style is more clean, we can disccuss it, refactor it. If you meet problems when you try to upgrade you extension from PHP to PHPng, let's add more info into the doc, or I can do some part of your work for you. as I have almost refactor all the extensions under ext/ and what do you want else? please, just, please, stop the worthless talking, I really don't want to see such useless words anymore.. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: About PHP NG document lacking argument
Hey: On Fri, Jul 25, 2014 at 2:56 PM, Laruence larue...@php.net wrote: Hey: First of all, I don't want to make *that* thead longer... as you can see, some devers says critically phpng is lacking of document, and they make that as the main reason for them to against phpng. I have to say, in my opinion it's totally ridiculous. 1. how many devers in here really knows zend engine? how many tried to know it? I assume a little, as you can see, only a few activate zend engine maintainers now. dmitry is the most experience one. 2. does PHP really has had a good API document? no, when I first tried to write a extension, I found no documents, or they was far beyond outdate, I event don't know how config.m4 works.. I learn PHP by reading the codes, and the example under ext/* 3. is document really important for PHPng? I don't think so, PHP can always read the codes, PHP is opensource , it is not *MS* who need document to tell people what it did in dark. 4. is PHPng API became more ugly? or harder to maintainable? I feel really bad to see somebody said such things... first of all. ugly, maintainable. it is too too subjective, and to be honest, it's obviously biased attitude. second, I , the main author of PHPNG, and Nikita, Dmitry, are the most activate internal contributors now. so you are saying we are writing ugly codes? I really can not agree with that. actually, the zend_hash API become more clear, and beatifuy than before. maintainable? who is the main force to maintain the PHP internal now? yes, the authors of PHPNG.. I think I have the more rights to say whether it is more maintainer able or not. and it's become more maintainable, because of more clean API and more reasonable logics. 5. are we going to write docs? yes, for people, who in love with PHP, who want to make PHP extensions, we are glad to write some APIs (which will be enough in a dever eye). actually we already doing it: https://wiki.php.net/phpng-upgrading 6. is PHPng really faster? yes, from my own test, it get more than 80% qps improvement in wordpress than php-5.6 . for those big PHP users, that means they can save lots of money. I see no reason to not have such a great change. anyone who tried to block such a amazing feature merge into PHP, is doing crime for PHP. I am not a native english speaker, so maybe I confused you in some words , sorry for that. I really hope the people in this group, the people who loves PHP, the people who want PHP become more popular here. stop less reasonable arguing, let's together to make this biggest change merge into PHP, make PHP users more easy life.. If you think we need write doc, let us write it. If you think we need more clean APIs? please tell me what style is more clean, we can disccuss it, refactor it. If you meet problems when you try to upgrade you extension from PHP to PHPng, let's add more info into the doc, or I can do some part of your work for you. as I have almost refactor all the extensions under ext/ and what do you want else? please, just, please, stop the worthless talking, I really don't want to see such useless words anymore.. for those who don't know me yet.. I am Xinchen Hui, from china, the author of the first PHP extension PHP framework Yaf, the first PHP occurrent RPC framework Yar, and Yac a user data cache. lua.. I am also the maintainer of msgpack, opcache. I start contribute to PHP from 2011, and I am also the main author of PHPNG I care performance of PHP very much, since I am also the chief architect of Weibo. we have thousands machines run PHP.. and * I will keep contributing to PHP, PHPNG *, so I think you could trust me that I love PHP, and PHP NG is the most amazing work I have participated in. thanks thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reporting bugs for phpng
Hey: On Fri, Jul 25, 2014 at 9:14 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Hi, I tried the .deb package for phpng that Zend provides since yesterday (thanks for that!) and I hit a memory consumption issue with the first of my scripts I tried: PHPNG: Memory peak: 62914560 (55.97MB) Elapsed time (s): 0.3383 PHP 5.5: Memory peak: 1835008 (1.64MB) Elapsed time (s): 0.0717 How/where can I make a bug report about it? Is https://bugs.php.net/ ok for PHPNG bugs? PHPNG is not listed in bugs.php.net yet. but as it's a branch of PHP , I think it's okey to report it there, and note it's PHPNG in the comment. for now. thanks Thanks Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpng - loss of IS_BOOL
Hey: On Wed, Jul 23, 2014 at 4:02 PM, Lester Caine les...@lsces.co.uk wrote: I'm trying to work through some of the more subtle changes in phpng and one that sticks out is the loss of IS_BOOL. I think the explanation is that it removes a read, but while I'm only seeing a few uses of is_bool across the codebase, every one of them is used simply to convert the bool value into some other format. Surely what would make more sense here is simply to make the type_flag either true or false, and retain the IS_BOOL as a single identifiable type? Having two types both indicating 'bool' just seems wrong. there is a _IS_BOOL macro to identifiable bool type.. you can use it in your own codes. thanks -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] An BC issue in unserialize
Hey:
I was trying play with OroCRM. then I find a BC break in PHP-5.6
the usage is :
/**
* Creates a new instance of the mapped class, without invoking
the constructor.
*
* @return object
*/
public function newInstance()
{
if ($this-_prototype === null) {
$this-_prototype = unserialize(sprintf('O:%d:%s:0:{}',
strlen($this-name), $this-name));
}
return clone $this-_prototype;
}
it works fine in PHP-5.5, but in 5.6 , the serialize will fail
after fix 5328d4289946e260232f3195ba2e0f0eb173d5ef
then I found, Stas did a re-fix for that:
342240fd7fb6ac0a287eb6f912c4d61d6274d68c
but it seems doesn't go into 5.6..
I am not sure now. should this usage be supported?
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An BC issue in unserialize
On Thu, Jul 17, 2014 at 1:09 PM, Remi Collet r...@fedoraproject.org wrote:
Le 17/07/2014 06:01, Laruence a écrit :
$this-_prototype = unserialize(sprintf('O:%d:%s:0:{}',
strlen($this-name), $this-name));
I am not sure now. should this usage be supported?
In think unserialize is an horrible hack which should have never be used.
This is described in UPGRADINGS
First, try to fix the code, using newInstanceWithoutConstructor() when
available (5.4+) and possible (userland classes)
Hey:
serialize maybe a sensitive area, in my opinion we should very
careful about the BC issue in such area..
if a user want to migrate it's codes from 5.5 to 5.6, but he has
multi servers, he might want to migrate them one by one.
in such case, the serialized data could be shared by 5.5 and 5.6...
so...
thanks
Remi.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Concurrency support for run-tests
On Mon, Jul 7, 2014 at 9:53 PM, Michael Wallner m...@php.net wrote: Hi! I also have a patch for run-tests sitting around for quite some time, which adds concurrent test execution support. I already fixed a lot of non re-entrant tests in the past, but there might still be quite some of them. Tests in ./Zend take 8 seconds instead of 30 on my box. Please find the hack attached. Thoughts, praises, death threats? I have dreamed for it for a long time.. thanks! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
Hey: On Mon, Jul 7, 2014 at 10:18 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! I've started the vote on the Uniform Variable Syntax RFC: https://wiki.php.net/rfc/uniform_variable_syntax#vote You can review the discussion about this RFC here: http://markmail.org/message/mr4ihbubfbdxygci The vote requires a 2/3 majority and is planned to end on 2014-07-14. The RFC targets PHP 6. sorry for didn't read the RFC before, but I can not vote for yes.. here are some words in RFC: 1. The current patch introduces a new “write context” issue. Namely ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = 'baz'. In the former case an undefined variable notice will be thrown if $foo does not exist, whereas the latter does not throw a notice. 2. As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6. I don't think we should introduce a new thing which is not perfect or confused.. it looks like we fixed a mess with a new mess. it make me think we should : don't fix it until it is broken thanks Thanks, Nikita -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
On Mon, Jul 7, 2014 at 10:46 PM, Andrea Faulds a...@ajf.me wrote: On 7 Jul 2014, at 15:42, Laruence larue...@php.net wrote: 1. The current patch introduces a new “write context” issue. Namely ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = 'baz'. In the former case an undefined variable notice will be thrown if $foo does not exist, whereas the latter does not throw a notice. 2. As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6. I don't think we should introduce a new thing which is not perfect or confused.. it looks like we fixed a mess with a new mess. it make me think we should : don't fix it until it is broken” We are fixing what is broken here; the variable syntax is counter-intuitive at the moment, and they make the syntax more consistent overall. Also, parentheses in PHP are always a source of issues. I don’t think they’ll ever quite work properly unless we switch to using an AST-based parser someday. then we won't need to temporarily fix it.. anyway, it's just my 2 cents thanks -- Andrea Faulds http://ajf.me/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
Hey: On Mon, Jul 7, 2014 at 10:46 PM, Andrea Faulds a...@ajf.me wrote: On 7 Jul 2014, at 15:42, Laruence larue...@php.net wrote: 1. The current patch introduces a new “write context” issue. Namely ($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] = 'baz'. In the former case an undefined variable notice will be thrown if $foo does not exist, whereas the latter does not throw a notice. 2. As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6. I don't think we should introduce a new thing which is not perfect or confused.. it looks like we fixed a mess with a new mess. it make me think we should : don't fix it until it is broken” We are fixing what is broken here; the variable syntax is counter-intuitive at the moment, and they make the syntax more consistent overall. Also, parentheses in PHP are always a source of issues. I don’t think they’ll ever quite work properly unless we switch to using an AST-based parser someday. I've change my opinion. I will vote for yes... thanks -- Andrea Faulds http://ajf.me/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Concurrency support for run-tests
Hey: On Mon, Jul 7, 2014 at 9:53 PM, Michael Wallner m...@php.net wrote: Hi! I also have a patch for run-tests sitting around for quite some time, which adds concurrent test execution support. I already fixed a lot of non re-entrant tests in the past, but there might still be quite some of them. Tests in ./Zend take 8 seconds instead of 30 on my box. Please find the hack attached. Thoughts, praises, death threats? seems it enable concurrency by default ? it's not configurable? maybe: TEST_PHP_ARGS=-c 3 make test means run 3 process thanks -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Hey: On Tue, Sep 24, 2013 at 10:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, There isn't any good counter measure session hijack. However, we can regenerate session ID if IP address has changed. Hijacked users might notice that they have been logged out if session ID is regenerated by attackers. Therefore, users have slight chance to notice that they were under attack. It's not greatly effective, but better than nothing. I don't think this is language concerning issue. it could be done in user script.. thanks Although this can be implemented in user script, it would be better if session module supports this behavior. Better security by default is good thing. It requires INI, since some apps may assume session ID would not change. (I do not encourage to use session ID for CSRF protection, but there are such implementations, for example.) A concern is that there are growing number of browsers share state. I do not research these browsers behavior yet. I suppose session cookie (expire=0) would not be shared. Anyone has any comments on this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Skipping parameters take 2
On Mon, Sep 2, 2013 at 3:17 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I've finally took some time to revive the skipping parameter RFC and patch. For those who doesn't remember what it is please see: https://wiki.php.net/rfc/skipparams TLDR version: The idea is to allow skipping parameters in function with optional arguments so that this: function create_query($where, $order_by, $join_type='INNER', $execute = false, $report_errors = true) can be called like this: create_query(deleted=0, name, default, default, /*report_errors*/ true); Hey: I am not sure whether this is a little overhead. but if we do want this. to be honest, I even prefer leave it empty to default. like create_query(delete=0, name, , , true); thanks Instead of trying to remember what the defaults are. The patch is here: https://github.com/php/php-src/pull/426 Any comments or feedback on the RFCs and the code are welcome, especially pointing out the cases where it may not work (which means we need more phpt's there :) -- 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [DRAFT] [RFC] Function autoloading
On Sat, Aug 31, 2013 at 12:13 AM, Leigh lei...@gmail.com wrote: On Aug 30, 2013 1:31 PM, Anthony Ferrara ircmax...@gmail.com wrote: For constants and function calls, the benchmark shows that the difference is well within the margin of error for the test (considering variances of 5% to 10% were common in my running of the tests). So hopefully this will dispel any worry about performance regressions in currently defined cases. The times where performance will take a hit, is with undefined functions and constants. Today, an undefined function will fatal error, so this performance hit would be 0, as it would enable something that's not possible today. I would assume there is actually potential for performance gain for functions being autoloaded in larger codebases when the *_once calls are removed that would normally load the common functions files. I just reply to this point: No. thinking we already have opcache there. so, *compiling* Functions is cheap. but if with function autoloading, *function autoloading* will execute every run. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Argument unpacking
On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! This RFC proposes to add a syntax for argument unpacking: https://wiki.php.net/rfc/argument_unpacking Basically, this is the complement of the variadics RFC: It is not about declaring variadic functions, but about calling them. The syntax it introduces looks as follows: $db-query($query, ...$params); seems so weird and ugly.. -1 thanks Thoughts? Thanks, Nikita -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 12:58 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! It is Oops, clicked too soon. I wanted to conclude that I think it is too many complications in the engine for too little gain. I agree with Stas here. thanks -- 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 RecursiveDirectoryIterator
Hey: On Tue, Aug 20, 2013 at 9:08 PM, Martin Keckeis martin.kecke...@gmail.com wrote: Hello together, an incompatible change was made to the 5.4 series without any notice. It's related to RecursiveDirectoryIterator https://bugs.php.net/bug.php?id=64228 See the source here: https://github.com/php/php-src/blob/PHP-5.4/ext/spl/spl_directory.c#L1452 I've never used the SKIP_DOTS parameter and so within the 5.4 series it may work or not... Drupal also had such an issue: https://drupal.org/node/1785216 Two things could be done IMO: - revert this change from 5.4 - mention it in the Upgrade Guide 5.3 - 5.4 that was a bug, that if you didn't pass SKIP_DOTS , dots should no be skipped. and this bug is also fixed in 5.3 branch. thanks Best regards Martin Keckeis -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
that maintain code bases built on top of 2nd party code, but meant to be used by 1st party developers. What does that mean? The average one-off application builder is likely to not get much use out of this (it can be used, but the problems for this group of people are mostly solved already). The average framework core-dev (like Symfony or ZF) isn't going to get *much* benefit out of this either (it can help in some areas, and they will use it, but it's not solving major problems). The Drupals, Magentos and Fuel CMS's of the world. The people who make plugins and modules for Frameworks and CMS's. Basically, the people who's lives will get MUCH easier with something like this are the people who maintain code that has a lot of dependencies, and that other people depend on (it sits in the middle of the dependency chain, where code on both sides is outside of their control). So if you don't see the usefulness of this type of change, ask if you maintain anything significant that fits that description. If you don't, find someone who does and talk to them. Otherwise you may be unfairly judging by ignoring problems that you personally don't have... what's going on here? Stas has been a core contributor for a long time, if he didn't meet such usage, then I think 80%(or more) people doesn't have this need either. to be honest, I don't think this is useful either... (in case you will doubt my qualification, let me introduce myself a little more, I am a 6 years PHP, 5 year C engineer, develped a lots of PHP applications, and also some big scalar ones, like weibo.com which I am maintaining now, thanks) interface is enough, interface is exactlly doing the protocol control thing, and I think it does very well. and it also very strict and reliable. so, why we need such feature that only a few people need it( if there really is some). and about the performance, runtime check on every methods's signature in runtime, how could it be faster than current way? if you bring 1% slowdown in one feature, yes, it's trivail, but if you bring such features 100 times? and, I have to clarifiy, the main reason I don't like this proposal is usage, not the performance.. and last, I am poor at english, so I usually don't like to argue. sorry if I didn't make myself clear. thanks Anthony PS: I updated the RFC with a number of use-cases, including the ability to hint on Traits (more specifically, the API of a trait)... -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Thu, Jun 27, 2013 at 10:54 PM, Laruence larue...@php.net wrote: On Thu, Jun 27, 2013 at 10:35 PM, Anthony Ferrara ircmax...@gmail.com wrote: Stas et al, So, the question of what is the difference between the two errors remains unanswered. If the whole diff is that one of the errors has word recoverable in the message, it's not substantial difference at all and one that does not require new syntax and big change in the language. I'm assuming that you do know the difference between E_RECOVERABLE_ERROR and E_ERROR. And the difference is not trivial... Internals should not be taking sides on what's good practice and what's bad practice (if it was, why the heck was goto introduced?). Instead, it Can we please lay the goto argument to rest? The argument goto was introduced, so feature X must too, because goto was introduced didn't sound good even the first time... I'm absolutely not trying to say we should include this because GOTO was introduced. I'm trying to point out the circular nature of the argument of good-vs-bad practice in general... should enable today's good practice to be followed. But it should not take a stand about bad practice. In my opinion, we should. We should not take into the language any concept that anyone considers useful in some particular piece of code. PHP language is very widely used, and we should consider how it would influence this huge ecosystem and if the overall effect would be beneficial and justify complicating (if there is one) the whole language system. Language is a system of thought and a system of approaching communication. IMO, this means it should have some principles and not just be a random bag of things that somebody at one point or another decided to stick into it, they should make sense together. PHP doesn't have the best reputation in this regard, but we are trying to make it better, not worse. It does not mean we should avoid change. It means we should have good reasons for change and carefully consider it. Good use cases IMO are prerequisite for that. Of course they are. Use-cases matter. A lot. But good practice vs not-good-practice shouldn't be a significant factor, because your good-practice is different from mine. And unless we as a group decide to stick to one interpretation (we haven't), then it's kind of pointless to talk about good practice. If you want to vote based on it, that's your prerogative. But in general I think that thought process is dangerous for the community as a whole and for core... My point here is that we should be judging features by their merit alone, and not by how we would use them. We also should not be judging them based upon our preferred style, but on the overall case of what it aims to achieve. IMO there's no merit in the feature besides its use. That's the only merit a feature could or should ever have. Ok, so then you agree that best-practice doesn't come into it at all...? Bringing this back on point, Duck-typing is a very valid and accepted way of doing OOP. In fact most other dynamic languages use this as the basis for their OOP system. This proposal does nothing but attempt to In fact, most other dynamic languages don't even have parameter typing. Neither Perl, Python, Ruby or Javascript have it. Let alone typing of the kind you suggest. What they have we have too. Duck typing for them doesn't mean what you propose - it means what we already have, checking type at the point of use. Check https://en.wikipedia.org/wiki/Duck_typing and see the examples - most of them don't have any typechecks. Referring to most dynamic languages while promoting this proposal is a bit misleading. Those other languages (all of them in fact) throw exceptions if the function or method does not exist. PHP hard fatals. They can live with pure duck-typing because their engines are designed to stay running, where ours is designed to fall on its face. This proposal is one attempt to bring some consistency and recoverability to the dynamic aspect of programming while providing for the ability to verify APIs at the engine level. One thing I find interesting is that I have discussed this feature with about 50 people at this point (quite a few at conferences and such before actually proposing it), and the sentiment elsewhere (not on list) was very predominately this solves a ton of problems. I find it interesting that on-list people seem to think that I'm making the use-cases up, and that there's not really a problem to solve. I wish some of the other people I talked to would speak up here ;-)... One thing to note is who the major audience for a feature like this is. It's not predominately for 1st party developers (developers writing one-off applications). It's not predominately for 2nd party developers (developers writing frameworks and other applications that have few dependencies and are intended to be used by 1st party developers
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Thu, Jun 27, 2013 at 11:25 PM, Anthony Ferrara ircmax...@gmail.com wrote: Laruence, I missed one thing here, it should be: why we need such feature that only a few people need it, and will also make reset people confused, and most of other language doesn't have it, and using it will make things a little mess(and low performance vs pure interface)? I've proven twice in this thread, and on the RFC itself that performance is equal to or **faster** than the current interface hints. Why does this subject keep coming up? Do you not believe my numbers? Run them yourself. The branch is available. And if you'd like, I can prove to you logically why performance is going to be better in cases where you don't implement interfaces but use Structural hinting. oh oh, take it easy, so are you saying, that check every method's signature of a class is *faster* than just check interface? I don't need to run the test at all If we're going to ignore the discussion and keep bringing issues that were put to bed back up again, there's no point continuing here. Because OMGS, ITS SLOW is the antithesis of a useful discussion once it's been shown that it's not... I didn't, did I? did I said *MOGS*? I really hope you could mind you temper here(if you was angry), thanks I was just saying, it is slow, but it's not my main reason to aginst it. As far as only a few people need it, last I checked, the Drupal community was not 'only a few people' (27k developers in the Drupal community alone), and several (at least 5) of their core contributors have expressed this feature solving some very significant problems they have been experiencing. So, 27k developers all think it's useful? But if you *really* think this feature is needed by only a few people, and that I'm blowing it way out of proportion (or inventing a problem), I'll retract this proposal. you don't need to retract this proposal just because I object it, I am just saying my opinion here. I would just highly recommend that you think about the assertion that you're making that you know the community's needs (to an 80% degree at least). That's a very significant thing to say, and I hope that you are willing to take the responsibility for that as well... Personally, I can only speak for the side of the community that I interact with regularly, which is by far not the entire community... ok, I am sorry about the 80%, it's just a 80:20 metaphor. I appreciate your effort to bring this here, and argu for it. and I was just doing the same thing, to argu it, and put my voice out. thanks Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UNKNOW:0, what is it?
On Thu, Jun 27, 2013 at 6:15 PM, Julien Pauli jpa...@php.net wrote: On Thu, Jun 27, 2013 at 11:31 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 27/06/13 06:40, Laruence wrote: thanks for the report, fixed in https://github.com/php/php-src/commit/fa8611c81ee72839cdff3e72b18cc586feb4aa29 thanks Thank you! But it seems that it is a regression because I didn't have this bug before. How can I fix this in my code? Any idea? What do you mean ? yes, I was confused too :) thanks You may have this in your code since long time, but not the exact scenario that triggers it. The patch let me think this bug has always been here (use of stack based pointer after the stack has been cleaned), simply noone did hit it before. Julien -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Thu, Jun 27, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote: Laruence, so are you saying, that check every method's signature of a class is *faster* than just check interface? Yes, yes I am saying that. And yes, the numbers show that. Think about it for a second. When you implement an interface, at compile time the compiler must loop through and check every methods signature for every interface. No matter if you ever type-hint against that interface or not. It always runs every class definition. And due to the point that opcode caches aren't caching this compilation step, it happens on every page load. So in the case where you implement an interface, but don't actually use that interface in any hints, you're still iterating through every method. My case only iterates through those methods when the hint is actually reached. So in the cases where the class never enters a hinted function/method, you wind up saving that iteration. So in that case it's significantly faster... In the case where both happens, all this does is delay the loop until run-time. So the iteration still happens (the same amount, as it happens for every unique class:interface pairing possible). In fact, the comparison is quite comparable (there are some minor differences, but not in terms of what's happening, just when it's happening). And once we have a comparison (successful or not), we cache it for the two class_entries involved. So then we never have to worry about executing it again. Therefore, structural hinting will be *worst-case* the same cost (statistically) as interfaces (it's just delaying the check to runtime instead of *every* compile). The average case (a cache hit, multiple checks of the same CE), structural will be faster as it's just a HT lookup instead of a recursive instanceof mapping. The best case (no hint), you *never* iterate through the methods in the first place. Sounds like a pretty convincing win on performance to me... Which is why it's kind of weird to keep hearing that it's slow to do, at least 6 times now in this thread... I don't need to run the test at all sigh... sigh, you made me to do the thing I really don't want to do, pull, config, make but fine... $ uname -a Darwin Laruence-Macbook.local 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 here is my test agianst your patch, for 3 times: [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.58958697319031 seconds, 5.8958697319031E-7 seconds per run Structural in 0.57371211051941 seconds, 5.7371211051941E-7 seconds per run Native in 0.34867691993713 seconds, 3.4867691993713E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.57501292228699 seconds, 5.7501292228699E-7 seconds per run Structural in 0.58277201652527 seconds, 5.8277201652527E-7 seconds per run Native in 0.33706784248352 seconds, 3.3706784248352E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.4509162903 seconds, 5.5554509162903E-7 seconds per run Structural in 0.59201097488403 seconds, 5.9201097488403E-7 seconds per run Native in 0.34463691711426 seconds, 3.4463691711426E-7 seconds per run as you can see, it only win one time!!! and after that, a more reallife like test I made, you can find it here:https://gist.github.com/laruence/5877870 run 3 times: $ sapi/cli/php /tmp/2.php Interface in 0.53591203689575 seconds, 5.3591203689575E-7 seconds per run Structural in 0.58459782600403 seconds, 5.8459782600403E-7 seconds per run Native in 0.34605598449707 seconds, 3.4605598449707E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/2.php Interface in 0.0718307495 seconds, 5.5550718307495E-7 seconds per run Structural in 0.59183287620544 seconds, 5.9183287620544E-7 seconds per run Native in 0.35443592071533 seconds, 3.5443592071533E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/2.php Interface in 0.5577380657196 seconds, 5.577380657196E-7 seconds per run Structural in 0.5662566948 seconds, 5.662566948E-7 seconds per run Native in 0.36081981658936 seconds, 3.6081981658936E-7 seconds per run it never won once! and there will be lots' of classes in reallife applications, you cache hashtable will resize... it will make thing worse.. and at last, I clarified again, it's not the main reason for me to agianst it thanks Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Fri, Jun 28, 2013 at 12:20 AM, Laruence larue...@php.net wrote: On Thu, Jun 27, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote: Laruence, so are you saying, that check every method's signature of a class is *faster* than just check interface? Yes, yes I am saying that. And yes, the numbers show that. Think about it for a second. When you implement an interface, at compile time the compiler must loop through and check every methods signature for every interface. No matter if you ever type-hint against that interface or not. It always runs every class definition. And due to the point that opcode caches aren't caching this compilation step, it happens on every page load. So in the case where you implement an interface, but don't actually use that interface in any hints, you're still iterating through every method. My case only iterates through those methods when the hint is actually reached. So in the cases where the class never enters a hinted function/method, you wind up saving that iteration. So in that case it's significantly faster... In the case where both happens, all this does is delay the loop until run-time. So the iteration still happens (the same amount, as it happens for every unique class:interface pairing possible). In fact, the comparison is quite comparable (there are some minor differences, but not in terms of what's happening, just when it's happening). And once we have a comparison (successful or not), we cache it for the two class_entries involved. So then we never have to worry about executing it again. Therefore, structural hinting will be *worst-case* the same cost (statistically) as interfaces (it's just delaying the check to runtime instead of *every* compile). The average case (a cache hit, multiple checks of the same CE), structural will be faster as it's just a HT lookup instead of a recursive instanceof mapping. The best case (no hint), you *never* iterate through the methods in the first place. Sounds like a pretty convincing win on performance to me... Which is why it's kind of weird to keep hearing that it's slow to do, at least 6 times now in this thread... I don't need to run the test at all sigh... sigh, you made me to do the thing I really don't want to do, pull, config, make but fine... $ uname -a Darwin Laruence-Macbook.local 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 here is my test agianst your patch, for 3 times: [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.58958697319031 seconds, 5.8958697319031E-7 seconds per run Structural in 0.57371211051941 seconds, 5.7371211051941E-7 seconds per run Native in 0.34867691993713 seconds, 3.4867691993713E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.57501292228699 seconds, 5.7501292228699E-7 seconds per run Structural in 0.58277201652527 seconds, 5.8277201652527E-7 seconds per run Native in 0.33706784248352 seconds, 3.3706784248352E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.4509162903 seconds, 5.5554509162903E-7 seconds per run Structural in 0.59201097488403 seconds, 5.9201097488403E-7 seconds per run Native in 0.34463691711426 seconds, 3.4463691711426E-7 seconds per run as you can see, it only win one time!!! and after that, a more reallife like test I made, you can find it here:https://gist.github.com/laruence/5877870 run 3 times: $ sapi/cli/php /tmp/2.php Interface in 0.53591203689575 seconds, 5.3591203689575E-7 seconds per run Structural in 0.58459782600403 seconds, 5.8459782600403E-7 seconds per run Native in 0.34605598449707 seconds, 3.4605598449707E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/2.php Interface in 0.0718307495 seconds, 5.5550718307495E-7 seconds per run Structural in 0.59183287620544 seconds, 5.9183287620544E-7 seconds per run Native in 0.35443592071533 seconds, 3.5443592071533E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/2.php Interface in 0.5577380657196 seconds, 5.577380657196E-7 seconds per run Structural in 0.5662566948 seconds, 5.662566948E-7 seconds per run Native in 0.36081981658936 seconds, 3.6081981658936E-7 seconds per run it never won once! and there will be lots' of classes in reallife applications, you cache hashtable will resize... it will make thing worse.. and at last, I clarified again, it's not the main reason for me to agianst it previous test script only measure the last all, although that, interface already won with complex arguments signatures... here is a fixed one: https://gist.github.com/laruence/5877928 run 3 times: $ sapi/cli/php /tmp/2.php Interface in 1.7314801216125 seconds
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Fri, Jun 28, 2013 at 12:30 AM, Laruence larue...@php.net wrote: On Fri, Jun 28, 2013 at 12:20 AM, Laruence larue...@php.net wrote: On Thu, Jun 27, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote: Laruence, so are you saying, that check every method's signature of a class is *faster* than just check interface? Yes, yes I am saying that. And yes, the numbers show that. Think about it for a second. When you implement an interface, at compile time the compiler must loop through and check every methods signature for every interface. No matter if you ever type-hint against that interface or not. It always runs every class definition. And due to the point that opcode caches aren't caching this compilation step, it happens on every page load. So in the case where you implement an interface, but don't actually use that interface in any hints, you're still iterating through every method. My case only iterates through those methods when the hint is actually reached. So in the cases where the class never enters a hinted function/method, you wind up saving that iteration. So in that case it's significantly faster... In the case where both happens, all this does is delay the loop until run-time. So the iteration still happens (the same amount, as it happens for every unique class:interface pairing possible). In fact, the comparison is quite comparable (there are some minor differences, but not in terms of what's happening, just when it's happening). And once we have a comparison (successful or not), we cache it for the two class_entries involved. So then we never have to worry about executing it again. Therefore, structural hinting will be *worst-case* the same cost (statistically) as interfaces (it's just delaying the check to runtime instead of *every* compile). The average case (a cache hit, multiple checks of the same CE), structural will be faster as it's just a HT lookup instead of a recursive instanceof mapping. The best case (no hint), you *never* iterate through the methods in the first place. Sounds like a pretty convincing win on performance to me... Which is why it's kind of weird to keep hearing that it's slow to do, at least 6 times now in this thread... I don't need to run the test at all sigh... sigh, you made me to do the thing I really don't want to do, pull, config, make but fine... $ uname -a Darwin Laruence-Macbook.local 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 here is my test agianst your patch, for 3 times: [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.58958697319031 seconds, 5.8958697319031E-7 seconds per run Structural in 0.57371211051941 seconds, 5.7371211051941E-7 seconds per run Native in 0.34867691993713 seconds, 3.4867691993713E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.57501292228699 seconds, 5.7501292228699E-7 seconds per run Structural in 0.58277201652527 seconds, 5.8277201652527E-7 seconds per run Native in 0.33706784248352 seconds, 3.3706784248352E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/1.php Interface in 0.4509162903 seconds, 5.5554509162903E-7 seconds per run Structural in 0.59201097488403 seconds, 5.9201097488403E-7 seconds per run Native in 0.34463691711426 seconds, 3.4463691711426E-7 seconds per run as you can see, it only win one time!!! and after that, a more reallife like test I made, you can find it here:https://gist.github.com/laruence/5877870 run 3 times: $ sapi/cli/php /tmp/2.php Interface in 0.53591203689575 seconds, 5.3591203689575E-7 seconds per run Structural in 0.58459782600403 seconds, 5.8459782600403E-7 seconds per run Native in 0.34605598449707 seconds, 3.4605598449707E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/2.php Interface in 0.0718307495 seconds, 5.5550718307495E-7 seconds per run Structural in 0.59183287620544 seconds, 5.9183287620544E-7 seconds per run Native in 0.35443592071533 seconds, 3.5443592071533E-7 seconds per run [Laruence@localhost:/Users/Laruence/opensource/trunk/] $ sapi/cli/php /tmp/2.php Interface in 0.5577380657196 seconds, 5.577380657196E-7 seconds per run Structural in 0.5662566948 seconds, 5.662566948E-7 seconds per run Native in 0.36081981658936 seconds, 3.6081981658936E-7 seconds per run it never won once! and there will be lots' of classes in reallife applications, you cache hashtable will resize... it will make thing worse.. and at last, I clarified again, it's not the main reason for me to agianst it previous test script only measure the last all, although that, interface already won with complex arguments signatures... here is a fixed one: https://gist.github.com/laruence/5877928 run 3
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
Hey: Instead of change the uint to long or size_t, Maybe make the max_file_upload_size 0 means unlimited? like Apached did, ulimited or = 2Gb https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody thanks On Thu, Jun 27, 2013 at 4:21 PM, Ralf Lang l...@b1-systems.de wrote: Hi, I want to deal with Bug 44522 which disallows uploads 2G https://bugs.php.net/bug.php?id=44522edit=1 Today with PHP cloud solutions, we are running into more situations where this really hurts. Before I begin providing a github patch (as I have no php svn access and I don't think it's needed) against master and possibly 5.5.next: Does anybody know of intricate reasons why the existing patch https://bugs.php.net/patch-display.php?bug_id=44522patch=uploads_larger_than_2g_HEAD_v2revision=latest could not be included into php 5.5? Or is it only what stas said in 2012: The patch however needs to be cleaned up (no IGNORE vars, etc.) and changing signature for zend_atoi may not be safe if any code out there presumes it returns int (integer overflow). Also, no reason to use signed long there where we used unsigned long. This would be my first patch against php core. Any pointers apreciated. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On Fri, Jun 28, 2013 at 1:12 PM, Laruence larue...@php.net wrote: Hey: Instead of change the uint to long or size_t, Maybe make the max_file_upload_size 0 means unlimited? like Apached did, ulimited or = 2Gb s ,Gb,GB, https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody thanks On Thu, Jun 27, 2013 at 4:21 PM, Ralf Lang l...@b1-systems.de wrote: Hi, I want to deal with Bug 44522 which disallows uploads 2G https://bugs.php.net/bug.php?id=44522edit=1 Today with PHP cloud solutions, we are running into more situations where this really hurts. Before I begin providing a github patch (as I have no php svn access and I don't think it's needed) against master and possibly 5.5.next: Does anybody know of intricate reasons why the existing patch https://bugs.php.net/patch-display.php?bug_id=44522patch=uploads_larger_than_2g_HEAD_v2revision=latest could not be included into php 5.5? Or is it only what stas said in 2012: The patch however needs to be cleaned up (no IGNORE vars, etc.) and changing signature for zend_atoi may not be safe if any code out there presumes it returns int (integer overflow). Also, no reason to use signed long there where we used unsigned long. This would be my first patch against php core. Any pointers apreciated. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UNKNOW:0, what is it?
On Thu, Jun 27, 2013 at 12:47 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 26/06/13 18:30, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:21 +0200, Ivan Enderlin @ Hoa wrote: On 26/06/13 18:19, Johannes Schlüter wrote: On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote: Hello, Again, I have a segfault with RecursiveDirectoryIterator when I extend it. This time, I have a very strange value on my SplFileInfo extension (subclass). When I var_dump the value, I have UNKNOWN:0. This is not a string, not null, not false, just UNKNOW:0, without type. Any idea of what is it? Thanks :-). Unknown is an unknown value in a structure when a zval is not properly set. Most likely you didn't call the parent's constructor. To bad, the constructor has been called :-(. The error is here: https://github.com/hoaproject/Iterator/blob/master/Recursive/Directory.php#L125. This is a line that causes the segfault. And at line 109, $this-getRelativePath() returns UNKNOWN:0. But if I var_dump $this-_relativePath directly (without using the method), I have a real value. I can't explain this. Try calling the parent ctor before doing anything with properties (i.e. setting _splFileInfoClass) If it doesn't fit please provide a complete reproduce script (and report a bug in any case) https://bugs.php.net/65136 here we are :-). thanks for the report, fixed in https://github.com/php/php-src/commit/fa8611c81ee72839cdff3e72b18cc586feb4aa29 thanks -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, I want to throw out this draft RFC to get the concept floating around and get feedback early. https://wiki.php.net/rfc/protocol_type_hinting There are still open questions, and a more complete (and cleaner) implementation will be needed before officially proposing it, but I wanted to get the concept out as soon as possible. What do you think? Hey: Just one question, usage? why we need this? (run-time check is slow and I can not think out of a case then we must need it) Go does that is not a reason... thanks Thanks! Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disabling the GC during shutdown
On Sat, Jun 22, 2013 at 6:06 PM, Arnaud Le Blanc arnaud...@gmail.com wrote: Hi, This bug may be related (and has a reproducing script) : https://bugs.php.net/bug.php?id=63734 Hey: I probably has fixed this bug(actually, according to the reporter this bug is due to Opcache): according to the latest feedback from the reporter: https://github.com/zendtech/ZendOptimizerPlus/issues/95#issuecomment-19854473 Incredible, but it works ! Tested ZendOptimizerPlus latest version (ba6c5f3) : segfault Applied your patch : fully works so, I think this bug is probable like the previous one we already fixed: https://github.com/php/php-src/commit/e88cdaa0 thanks On Sat, Jun 22, 2013 at 4:41 AM, Andi Gutmans a...@zend.com wrote: -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Thursday, June 20, 2013 8:20 PM To: Anthony Ferrara Cc: Laruence; internals@lists.php.net Subject: Re: [PHP-DEV] Disabling the GC during shutdown However, that's not really fixing the situation either, as the zval is still getting nuked (but only partially). If there's a memory overwrite or use-after-free is going on, this patch is not a complete solution - it relies on the fact that bad data will be always out of range of good data. I see no way to ensure that - so if there's an overwrite that writes garbage inside the object there will be situations where the garbage looks exactly like a valid object ID and it will still crash, but it would be significantly harder to reproduce. So I think before patching it we need to get to the root cause and figure out why it happens and what causes it, instead of partially fixing the symptom I agree with that. I think it'd be a mistake to submit any patch without us understanding root cause. We may cover up a bug which will resurface elsewhere... Hopefully you can find a way to pin it down. Thanks for putting this much effort into it! Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disabling the GC during shutdown
On Thu, Jun 20, 2013 at 1:46 AM, Anthony Ferrara ircmax...@gmail.com wrote: All, We were discussing a range of bugs today with the garbage collector. For example: https://bugs.php.net/bug.php?id=64827 After quite a bit of digging, it appears what's happening is that the garbage collector is running during the shutdown of PHP. So the destructors are fired, and the variables are being destroyed when the GC run happens. This means that the GC, while walking the variable tree runs into a partially destructed object (where an entry of the hash table has already been freed). This causes a segfault, and fun ensues. Hey: Sorry, but I don't this this explain is right. if there is more than one refcount to a zval, then it should never be freed and if a zval is freed, then it must also be removed from the gc roots. according to your explain, the gc segfault while walking through a hashtable of a object. but that doesn't make any sense, since if it segfault in walking, then it should also segfault when trying to free the hash table later while dtor the object. disable GC in shutdown is okey for me. but that is just try to cover the bug somewhere in the refcount handler.. not the right fix. thanks Under normal conditions (not during shutdown), this does not appear to be an issue, because the zval is destructed prior to the object destruction. This means that there should never be a case where the GC hits a partially freed object during normal execution. From what I can see, there are two possible fixes. The first would be to change how object destruction works in the first place, to tie the variable into the destruction process (basically refactor the object delref API to also accept the current zval). That way the part of the code that makes the decision to nuke the object can nuke the zval first (and hence prevent this condition). However, this is a major API change and would effect a lot of extensions that are using or tieing into this hook. The other option would be to simply disable the GC on shutdown. Considering all of the variables are going to be thrown away anyway, having the GC run during shutdown seems a bit wasteful anyway. So if we can kill two birds with one stone, why not? I've prepared a basic patch: https://github.com/ircmaxell/php-src/compare/gc_deactivate_on_shutdown I did confirm with odoucet (one of the original reporters) that this does clear up his issue: https://gist.github.com/odoucet/5796378 (along with trying a bunch of other things). There are a few out standing questions though: 1. Technically, all we need to do is force GC_G(gc_enabled) = 0 in shutdown. But we could also use zend_alter_ini_entry which has the same effect. The question comes is there any reason to go through the overhead of altering the ini entry instead of the global directly? We do access the global directly in other areas (but it's typically only set via ini)... 2. I put it in php_request_shutdown() after deactivate_ticks, but before it calls shutdown functions. I could see it being moved after the shutdown function call, but I'm not sure if it's worth it (either way). thoughts? 3. Can anyone think of a reason we'd want the GC enabled during the request shutdown? I can't think of any... Additionally, considering that this does solve a segfault, is it worth nominating this for 5.3? Or is it too risky (or something else I'm missing)... Thanks, Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disabling the GC during shutdown
On Thu, Jun 20, 2013 at 6:12 PM, Laruence larue...@php.net wrote: On Thu, Jun 20, 2013 at 1:46 AM, Anthony Ferrara ircmax...@gmail.com wrote: All, We were discussing a range of bugs today with the garbage collector. For example: https://bugs.php.net/bug.php?id=64827 After quite a bit of digging, it appears what's happening is that the garbage collector is running during the shutdown of PHP. So the destructors are fired, and the variables are being destroyed when the GC run happens. This means that the GC, while walking the variable tree runs into a partially destructed object (where an entry of the hash table has already been freed). This causes a segfault, and fun ensues. Hey: Sorry, but I don't this this explain is right. if there is more than one refcount to a zval, then it should never be freed and if a zval is freed, then it must also be removed from the gc roots. according to your explain, the gc segfault while walking through a hashtable of a object. but that doesn't make any sense, since if it segfault in walking, then it should also segfault when trying to free the hash table later while dtor the object. disable GC in shutdown is okey for me. but that is just try to cover the bug somewhere in the refcount handler.. not the right fix. thanks And actually, I prefer not doing this(disable gc in shutdown) for now, because maybe someday we can get a simple reproduce script(as we all have see, it is very rare). then the segfault will be fixed, in the right way. thanks Under normal conditions (not during shutdown), this does not appear to be an issue, because the zval is destructed prior to the object destruction. This means that there should never be a case where the GC hits a partially freed object during normal execution. From what I can see, there are two possible fixes. The first would be to change how object destruction works in the first place, to tie the variable into the destruction process (basically refactor the object delref API to also accept the current zval). That way the part of the code that makes the decision to nuke the object can nuke the zval first (and hence prevent this condition). However, this is a major API change and would effect a lot of extensions that are using or tieing into this hook. The other option would be to simply disable the GC on shutdown. Considering all of the variables are going to be thrown away anyway, having the GC run during shutdown seems a bit wasteful anyway. So if we can kill two birds with one stone, why not? I've prepared a basic patch: https://github.com/ircmaxell/php-src/compare/gc_deactivate_on_shutdown I did confirm with odoucet (one of the original reporters) that this does clear up his issue: https://gist.github.com/odoucet/5796378 (along with trying a bunch of other things). There are a few out standing questions though: 1. Technically, all we need to do is force GC_G(gc_enabled) = 0 in shutdown. But we could also use zend_alter_ini_entry which has the same effect. The question comes is there any reason to go through the overhead of altering the ini entry instead of the global directly? We do access the global directly in other areas (but it's typically only set via ini)... 2. I put it in php_request_shutdown() after deactivate_ticks, but before it calls shutdown functions. I could see it being moved after the shutdown function call, but I'm not sure if it's worth it (either way). thoughts? 3. Can anyone think of a reason we'd want the GC enabled during the request shutdown? I can't think of any... Additionally, considering that this does solve a segfault, is it worth nominating this for 5.3? Or is it too risky (or something else I'm missing)... Thanks, Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 and APC user cache upgrade path
On Sat, May 11, 2013 at 6:30 PM, Joe Watkins krak...@php.net wrote: On 05/11/2013 11:10 AM, Joe Watkins wrote: On 05/10/2013 08:54 PM, Christopher Jones wrote: On 05/09/2013 05:02 AM, Pierre Schmitz wrote: Hi, I am testing PHP 5.5 atm and how we can package it for Arch Linux and provide an upgrade path for users. The RC1 looks pretty solid so far. As the new opcache does not provide a user cache to store custom variables, I would be glad if you could clarify what the best migration from 5.4 would be. * Is APC basically dead and wont support PHP 5.5? From the lack of APC activity and from comments Rasmus has made in the bugs (e.g. [1]) this is a safe assumption. * Should APC users switch to opcache and APCu? (with APCu replacing the APC package) OPcache is definitely the opcode cache solution for PHP 5.5 For user data caches, there are a number of alternatives, as you noted. During this initial transition phase it isn't clear what the directions of each solution will be. It isn't clear that there will be one dominant solution. I'll leave it to Laruence and Joe to state their cases for world domination of YAC and APCu, respectively. Chris [1] https://bugs.php.net/bug.php?**id=64625https://bugs.php.net/bug.php?id=64625 For PHP application developers: * Regarding APCu: it provides the old PHP interface function as well as their own apcu_* functions. They are aliases right now. Should application developers think about switching to the apcu_-API as new features will be available only here? Bonus question: * Right now very similar functionality is provided by APCu, XCache, WinCache, YAC etc.. Are there plans to include such functionality inside PHP in future to make application developers life a little easier? At least a common API would be great. There were several bugs in applications as these modules behave a little different regarding return values etc.. Greetings, Pierre I am still waiting to see articles/blogs and the consensus on YAC. YAC has a much higher throughput, if you are able to write the software to manage it and have the hardware to put up with it, then you should attempt to take advantage. I'm not really sure if most have either the ability or the hardware; or if it's good thing to aspire to having either. Think about what is the advantage of using a cache, why does it create a more stable experience even when we do have the hardware to SELECT or request everything we need from wherever it comes ... it's because you are benefiting from the fact that the cache doesn't just make PHP faster because the opcodes Zend executes are less than fetching an un-cached result, but also, and mostly because it takes the pressure of MySQL, or your network connection, or your IO scheduler, or all of the above if you are clever about it. The problem with having no locking comes on a loaded server when many clients are attempting to read from an expired entry (this is the point where a cache has the effect of a stable service even under load where items have short ttls) the cache so they can avoid some significant work. In that situation, APC (and most others I assume) has a lock acquired by the first writer that cannot be obtained by a reader while it is held, the writer finishes (populating cache) the reader acquires the lock and is able to read that cached item, as are other readers. Good, only one context done what the cache is there to avoid. With YAC, or any solution that does not employ entry level locking, many contexts will end up doing the work, because a reader cannot see what isn't finished writing and will not implicitly wait for a write to complete. Something to think about ... Joe Not entry level, cache level locking. Entry level I tested and it just makes the software more complex and work harder for no improvement evident over read/write locks, and no significant benefit over apcu's implementation of standard locking (used where rwlocks are disabled explicitly) ... sorry for missed this message, hehe Yac is designed for user relevant caches, in our applications, cache are always bind to a specific user(cache key is prefix with user_id), in this case, Yac is very situable, since there is no Thundering herd... for these casese, like cache a config file, once the config file is modified, then multi-process will try to update it. I assume in this case, Yac will get a overhead costs, anyway, I am busy about some else work recently, I will definitly write some blogs/articles about Yaf in reallife applications later. (... and windows support) thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] PHP 5.5 and APC user cache upgrade path
Hey: besides APCu, you can also have a try with : https://github.com/laruence/yac :) thanks On Thu, May 9, 2013 at 8:02 PM, Pierre Schmitz pie...@archlinux.de wrote: Hi, I am testing PHP 5.5 atm and how we can package it for Arch Linux and provide an upgrade path for users. The RC1 looks pretty solid so far. As the new opcache does not provide a user cache to store custom variables, I would be glad if you could clarify what the best migration from 5.4 would be. * Is APC basically dead and wont support PHP 5.5? * Should APC users switch to opcache and APCu? (with APCu replacing the APC package) For PHP application developers: * Regarding APCu: it provides the old PHP interface function as well as their own apcu_* functions. They are aliases right now. Should application developers think about switching to the apcu_-API as new features will be available only here? Bonus question: * Right now very similar functionality is provided by APCu, XCache, WinCache, YAC etc.. Are there plans to include such functionality inside PHP in future to make application developers life a little easier? At least a common API would be great. There were several bugs in applications as these modules behave a little different regarding return values etc.. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/
[PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback
Hey:
Sorry for the delay, the new patch, which make the second argument the
regex array keys is attached.
https://bugs.php.net/patch-display.php?bug_id=64730patch=second_arg_rege_key.patchrevision=latest
with this patch, preg_replace_callback will call user callback with two
arguments, the first one is the same, the second is the regex key if the
regex is an array or NULL if the regex is a string.
then we can do something like:
$code = preg_replace_callback(
array(
foo = /some very complex regex/,
bar = /another one/,
...
),
function($matches, $idx) {
switch ($idx) {
case 'foo'
...
case 'bar':
...
}
},
$code);
if no objections, I will commit this patch after 5.5. 0 final release..
thanks
On Tue, Apr 30, 2013 at 12:46 AM, Laruence larue...@php.net wrote:
Hey:
there comes a FR: https://bugs.php.net/bug.php?id=64730
the main idea is, in 5.5 we remove support of 'e' modifier.
then comes a problem, the old codes(a real use case see
https://github.com/php/php-src/blob/PHP-5.4/Zend/zend_vm_gen.php#L390):
preg_replace(array(
/pattern1(.*)/,
/pattern2(.*)/
),
array(
/replace1/e,
/replace2/e
)
..),
can not be easier convert to the callback style.
then I have to change it to something very ugly like(a real use case
see: https://github.com/php/php-src/blob/PHP-5.5/Zend/zend_vm_gen.php#L390
):
function callback($subject) {
if (!strncmp($subject, pattern1, 8)) {
//function for pattern 1
} else if(!strncmp($subject, pattern2, 8)) {
//function for pattern 2
} else .
}
so I propose to add a second argument to callback(aim to php-5.5.1),
which is the matched regex string self.
then I can simplify the previous codes to:
function callback ($subject, $regex) {
$replace_funcs = array(
/pattern1(.*) = function ($subect) { //function for
parttern 1; },
/pattern2(.*) = function($sbuect) { //function for
pattern 2; }
);
$replace_funcs[$regex]($subject);
}
what do you think(of course, the second argument can also easily change
to be the regex idx in the regex array)?
patch is here:
https://bugs.php.net/patch-display.php?bug_id=64730patch=sencode_argument.patchrevision=latest
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback
On Sat, May 4, 2013 at 8:49 PM, Nikita Popov nikita@gmail.com wrote:
On Sat, May 4, 2013 at 2:39 PM, Laruence larue...@php.net wrote:
Hey:
Sorry for the delay, the new patch, which make the second argument the
regex array keys is attached.
https://bugs.php.net/patch-display.php?bug_id=64730patch=second_arg_rege_key.patchrevision=latest
with this patch, preg_replace_callback will call user callback with
two
arguments, the first one is the same, the second is the regex key if the
regex is an array or NULL if the regex is a string.
then we can do something like:
$code = preg_replace_callback(
array(
foo = /some very complex regex/,
bar = /another one/,
...
),
function($matches, $idx) {
switch ($idx) {
case 'foo'
...
case 'bar':
...
}
},
$code);
if no objections, I will commit this patch after 5.5. 0 final release..
thanks
I object. If this were using the preg_replace_callback(Array, Array,
String) syntax [which is not practically possible due to ambiguity], I
would agree that this is a nice feature which makes the function consistent
with preg_replace and str_replace. But this implementation with some weird
additional identifier that you need to switch over makes absolutely no
sense to me and only complicated the API. Better to just use a loop for
this.
if you got an better solution, please propose it.
only object won't help much here, since the problem is there, we need to
solve it.
thanks
One thing that might be nicer API wise but without ambiguity is an
preg_replace_callback(['regex' = callback], $string) overload. Though
personally I'm not really a fan of doing overloads with completely
different argument types.
Nikita
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback
On Sat, May 4, 2013 at 8:49 PM, Nikita Popov nikita@gmail.com wrote:
On Sat, May 4, 2013 at 2:39 PM, Laruence larue...@php.net wrote:
Hey:
Sorry for the delay, the new patch, which make the second argument the
regex array keys is attached.
https://bugs.php.net/patch-display.php?bug_id=64730patch=second_arg_rege_key.patchrevision=latest
with this patch, preg_replace_callback will call user callback with
two
arguments, the first one is the same, the second is the regex key if the
regex is an array or NULL if the regex is a string.
then we can do something like:
$code = preg_replace_callback(
array(
foo = /some very complex regex/,
bar = /another one/,
...
),
function($matches, $idx) {
switch ($idx) {
case 'foo'
...
case 'bar':
...
}
},
$code);
if no objections, I will commit this patch after 5.5. 0 final release..
thanks
I object. If this were using the preg_replace_callback(Array, Array,
String) syntax [which is not practically possible due to ambiguity], I
would agree that this is a nice feature which makes the function consistent
with preg_replace and str_replace. But this implementation with some weird
additional identifier that you need to switch over makes absolutely no
sense to me and only complicated the API. Better to just use a loop for
this.
And, I *DO NOT* think it's weird, it's few choice we got now..
because:
As I said, a loop is inefficient here.
One thing that might be nicer API wise but without ambiguity is an
preg_replace_callback(['regex' = callback], $string) overload. Though
personally I'm not really a fan of doing overloads with completely
different argument types.
I don't this this is possible..
thinking of :
$regex = array(0 = xxx);
if by accident there is a function call xxx.
thanks
Nikita
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback
On Sat, May 4, 2013 at 8:58 PM, Nikita Popov nikita@gmail.com wrote:
On Sat, May 4, 2013 at 2:52 PM, Laruence larue...@php.net wrote:
On Sat, May 4, 2013 at 8:49 PM, Nikita Popov nikita@gmail.comwrote:
On Sat, May 4, 2013 at 2:39 PM, Laruence larue...@php.net wrote:
Hey:
Sorry for the delay, the new patch, which make the second argument
the
regex array keys is attached.
https://bugs.php.net/patch-display.php?bug_id=64730patch=second_arg_rege_key.patchrevision=latest
with this patch, preg_replace_callback will call user callback with
two
arguments, the first one is the same, the second is the regex key if
the
regex is an array or NULL if the regex is a string.
then we can do something like:
$code = preg_replace_callback(
array(
foo = /some very complex regex/,
bar = /another one/,
...
),
function($matches, $idx) {
switch ($idx) {
case 'foo'
...
case 'bar':
...
}
},
$code);
if no objections, I will commit this patch after 5.5. 0 final
release..
thanks
I object. If this were using the preg_replace_callback(Array, Array,
String) syntax [which is not practically possible due to ambiguity], I
would agree that this is a nice feature which makes the function consistent
with preg_replace and str_replace. But this implementation with some weird
additional identifier that you need to switch over makes absolutely no
sense to me and only complicated the API. Better to just use a loop for
this.
if you got an better solution, please propose it.
only object won't help much here, since the problem is there, we need to
solve it.
thanks
Sorry, but what problem is there again? As I already said earlier, you can
just use a loop:
foreach ($replacements as $regex = $callback) {
$str = preg_replace_callback($regex, $callback, $str);
}
So if there are 10 regex in the array, you will got 10 DO_FCALL. 10 times
arguments accept, 10 times etc...
and AS I already said: IT is inefficient. I personally can not accept it.
thanks
Which is both clearer and requires less code.
Nikita
--
Laruence Xinchen Hui
http://www.laruence.com/
[PHP-DEV] [RFC] Add a second argument to callback of preg_replace_callback
Hey: I thought it is a minor change, so was not plan to make a RFC .. but since there are some insistent objections, I think a RFC is better. let's people vote for it. here is the RFC: https://wiki.php.net/rfc/second_arg_to_preg_callback and objections are also listed. thanks -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback
On Sat, May 4, 2013 at 9:46 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Laruence,
foreach ($replacements as $regex = $callback) {
$str = preg_replace_callback($regex, $callback, $str);
}
So if there are 10 regex in the array, you will got 10 DO_FCALL. 10
times
arguments accept, 10 times etc...
and AS I already said: IT is inefficient. I personally can not accept
it.
thanks
My initial reaction was that the difference in runtime is going to be so
insignificant that it's the very definition of a micro-optimization between
the two. And unless you're doing it millions of times in a hot-loop, it's
never even going to be realized. I was going to reply to that effect.
Then I decided to write a quick test.
$count = 100;
$start = microtime(true);
for ($i = 0; $i $count; $i++) {
$str = abc;
$str = preg_replace_callback('/a/', function($a) { return
strtoupper($a[0]); }, $str);
$str = preg_replace_callback('/b/', function($a) { return
strtoupper($a[0]); }, $str);
$str = preg_replace_callback('/c/', function($a) { return
strtoupper($a[0]); }, $str);
$str = preg_replace_callback('/a/', function($a) { return
strtolower($a[0]); }, $str);
$str = preg_replace_callback('/b/', function($a) { return
strtolower($a[0]); }, $str);
$str = preg_replace_callback('/c/', function($a) { return
strtolower($a[0]); }, $str);
}
echo Completed in . (microtime(true) - $start) . Seconds\n;
$start = microtime(true);
for ($i = 0; $i $count; $i++) {
$str = abc;
$str = preg_replace(array(
'/a/e',
'/b/e',
'/c/e',
'/a/e',
'/b/e',
'/c/e',
),
array(
'strtoupper(\'$1\')',
'strtoupper(\'$1\')',
'strtoupper(\'$1\')',
'strtolower(\'$1\')',
'strtolower(\'$1\')',
'strtolower(\'$1\')',
),
$str
);
}
echo Completed in . (microtime(true) - $start) . Seconds\n;
So basically, it's comparing the old behavior (one call to preg_replace)
that you want to emulate, with what Nikita is suggesting.
I ran it on 3v4l (http://3v4l.org/dRjtU) and the results were quite
surprising. I was expecting the first to be slightly slower than the
second. But the reality surprised me:
Completed in 0.00076389312744141 Seconds Completed in 0.0012428760528564
Seconds
As it turns out, calling preg_replace_callback() multiple times is almost
50% faster than using a single call to preg_replace().
It's likely due to the precompiled nature of closures, vs the compilation
happening multiple times at invocation in the preg_replace /e case.
But it's still worth noting that switching from the /e style to a more
traditional preg_replace_callback implementation will get you a significant
boost in performance of that.
Now, keep in mind, we're talking 0.05 seconds saved per execution
(group of 6 replacements). So it's not likely to matter much or be worth
worrying about...
Hey:
thanks for the benchmark, but please don't think it's useless just
because it's monior
PHP is a web program language, let's think about a high trafiic site,
which get 100, 000, 000 pv perday.
100, 000, 000 * 0.005 = 500s perday
and inefficent not always means performance only, in this case , you
need to define various functions for different regexs if you use loop style.
and do you prefer array_walk or foreach when you try to iteraterly
process an array?
thanks
My $0.02 at least...
Anthony
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Re: [PROPOSAL]Add second to callback of preg_replace_callback
I made a RFC for this: https://wiki.php.net/rfc/second_arg_to_preg_callback
thanks
On Sat, May 4, 2013 at 10:28 PM, Laruence larue...@php.net wrote:
On Sat, May 4, 2013 at 9:46 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Laruence,
foreach ($replacements as $regex = $callback) {
$str = preg_replace_callback($regex, $callback, $str);
}
So if there are 10 regex in the array, you will got 10 DO_FCALL. 10
times
arguments accept, 10 times etc...
and AS I already said: IT is inefficient. I personally can not accept
it.
thanks
My initial reaction was that the difference in runtime is going to be so
insignificant that it's the very definition of a micro-optimization
between
the two. And unless you're doing it millions of times in a hot-loop, it's
never even going to be realized. I was going to reply to that effect.
Then I decided to write a quick test.
$count = 100;
$start = microtime(true);
for ($i = 0; $i $count; $i++) {
$str = abc;
$str = preg_replace_callback('/a/', function($a) { return
strtoupper($a[0]); }, $str);
$str = preg_replace_callback('/b/', function($a) { return
strtoupper($a[0]); }, $str);
$str = preg_replace_callback('/c/', function($a) { return
strtoupper($a[0]); }, $str);
$str = preg_replace_callback('/a/', function($a) { return
strtolower($a[0]); }, $str);
$str = preg_replace_callback('/b/', function($a) { return
strtolower($a[0]); }, $str);
$str = preg_replace_callback('/c/', function($a) { return
strtolower($a[0]); }, $str);
}
echo Completed in . (microtime(true) - $start) . Seconds\n;
$start = microtime(true);
for ($i = 0; $i $count; $i++) {
$str = abc;
$str = preg_replace(array(
'/a/e',
'/b/e',
'/c/e',
'/a/e',
'/b/e',
'/c/e',
),
array(
'strtoupper(\'$1\')',
'strtoupper(\'$1\')',
'strtoupper(\'$1\')',
'strtolower(\'$1\')',
'strtolower(\'$1\')',
'strtolower(\'$1\')',
),
$str
);
}
echo Completed in . (microtime(true) - $start) . Seconds\n;
So basically, it's comparing the old behavior (one call to preg_replace)
that you want to emulate, with what Nikita is suggesting.
I ran it on 3v4l (http://3v4l.org/dRjtU) and the results were quite
surprising. I was expecting the first to be slightly slower than the
second. But the reality surprised me:
Completed in 0.00076389312744141 Seconds Completed in 0.0012428760528564
Seconds
As it turns out, calling preg_replace_callback() multiple times is almost
50% faster than using a single call to preg_replace().
It's likely due to the precompiled nature of closures, vs the compilation
happening multiple times at invocation in the preg_replace /e case.
But it's still worth noting that switching from the /e style to a more
traditional preg_replace_callback implementation will get you a
significant
boost in performance of that.
Now, keep in mind, we're talking 0.05 seconds saved per execution
(group of 6 replacements). So it's not likely to matter much or be worth
worrying about...
Hey:
thanks for the benchmark, but please don't think it's useless just
because it's monior
PHP is a web program language, let's think about a high trafiic site,
which get 100, 000, 000 pv perday.
100, 000, 000 * 0.005 = 500s perday
and inefficent not always means performance only, in this case , you
need to define various functions for different regexs if you use loop style.
and do you prefer array_walk or foreach when you try to iteraterly
process an array?
thanks
My $0.02 at least...
Anthony
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
[PHP-DEV] [PROPOSAL]Add second to callback of preg_replace_callback
Hey:
there comes a FR: https://bugs.php.net/bug.php?id=64730
the main idea is, in 5.5 we remove support of 'e' modifier.
then comes a problem, the old codes(a real use case see
https://github.com/php/php-src/blob/PHP-5.4/Zend/zend_vm_gen.php#L390):
preg_replace(array(
/pattern1(.*)/,
/pattern2(.*)/
),
array(
/replace1/e,
/replace2/e
)
..),
can not be easier convert to the callback style.
then I have to change it to something very ugly like(a real use case
see: https://github.com/php/php-src/blob/PHP-5.5/Zend/zend_vm_gen.php#L390):
function callback($subject) {
if (!strncmp($subject, pattern1, 8)) {
//function for pattern 1
} else if(!strncmp($subject, pattern2, 8)) {
//function for pattern 2
} else .
}
so I propose to add a second argument to callback(aim to php-5.5.1),
which is the matched regex string self.
then I can simplify the previous codes to:
function callback ($subject, $regex) {
$replace_funcs = array(
/pattern1(.*) = function ($subect) { //function for
parttern 1; },
/pattern2(.*) = function($sbuect) { //function for pattern
2; }
);
$replace_funcs[$regex]($subject);
}
what do you think(of course, the second argument can also easily change
to be the regex idx in the regex array)?
patch is here:
https://bugs.php.net/patch-display.php?bug_id=64730patch=sencode_argument.patchrevision=latest
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] [PROPOSAL]Add second to callback of preg_replace_callback
On Tue, Apr 30, 2013 at 1:43 AM, Nikita Popov nikita@gmail.com wrote:
On Mon, Apr 29, 2013 at 6:46 PM, Laruence larue...@php.net wrote:
Hey:
there comes a FR: https://bugs.php.net/bug.php?id=64730
the main idea is, in 5.5 we remove support of 'e' modifier.
then comes a problem, the old codes(a real use case see
https://github.com/php/php-src/blob/PHP-5.4/Zend/zend_vm_gen.php#L390):
preg_replace(array(
/pattern1(.*)/,
/pattern2(.*)/
),
array(
/replace1/e,
/replace2/e
)
..),
can not be easier convert to the callback style.
then I have to change it to something very ugly like(a real use case
see:
https://github.com/php/php-src/blob/PHP-5.5/Zend/zend_vm_gen.php#L390):
function callback($subject) {
if (!strncmp($subject, pattern1, 8)) {
//function for pattern 1
} else if(!strncmp($subject, pattern2, 8)) {
//function for pattern 2
} else .
}
so I propose to add a second argument to callback(aim to php-5.5.1),
which is the matched regex string self.
then I can simplify the previous codes to:
function callback ($subject, $regex) {
$replace_funcs = array(
/pattern1(.*) = function ($subect) { //function for
parttern 1; },
/pattern2(.*) = function($sbuect) { //function for
pattern
2; }
);
$replace_funcs[$regex]($subject);
}
what do you think(of course, the second argument can also easily change
to be the regex idx in the regex array)?
patch is here:
https://bugs.php.net/patch-display.php?bug_id=64730patch=sencode_argument.patchrevision=latest
What's wrong with this?
$replacements = ['regex' = 'callback'];
foreach ($replacements as $regex = $callback) {
$str = preg_replace_callback($regex, $callback, $str);
hey:
efficiency simplicity
do you use foreach even there is array_map?
thanks
}
Nikita
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Re: [lists.php] [PHP-DEV] [PROPOSAL]Add second to callback of preg_replace_callback
On Tue, Apr 30, 2013 at 5:53 AM, ALeX lists@tx0.eu wrote:
what about patch preg_replace to accept callbacks?
example:
preg_replace(array(
/pattern1(.*)/,
/pattern2(.*)/
),
array(
function ($pat) { ... } ,
replace
)
, ... );
Hey:
then I think perg_replace_callback become useless
thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
hey: thanks very much for all feedbacks. so, maybe we should document this instead of adding lead backslash? thanks On Wed, Apr 10, 2013 at 5:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 04/09/2013 01:23 PM, Madara Uchiha wrote: Well, why would you need to serialize an object in one version of PHP, and unserialize it in another? Unfortunately people do that all the time. They store serialized versions of stuff in databases and other backends and even send it across the wire from one machine to another, so it is quite common for something serialized in one version to need to be unserialized in another. -Rasmus -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
Hey;
I think it's a great idea, if all op_arrays in one script share the same
literals table, let's say it's main scope 's literals table.
then we can make all class entry, function entry share the same constant
literal..
image that, same class(function) only need to lookup once in one
script.. rest will all hits cache I think we can gain significant
peformance improve there.
thanks
On Wed, Apr 10, 2013 at 7:57 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Recently, I've found that OPcache optimizer misses a lot of abilities,
because it handles only one op_array at once. So it definitely can't
perform any inter-function optimizations (e.g. inlining).
Actually, it was not very difficult to switch to script at once approach.
The attached patch demonstrates it and adds per script constants
substitution explained in the following script
?php
define(FOO, 1);
function foo() {
echo FOO . \n; // optimizer will replace it with: echo 1\n;
}
?
Of course, I ran the PHP test suite and it passed all the same tests.
Personally, I think it's safe to include this patch into 5.5 and make a
green light to some other advanced optimizations in 5.5. (e.g. conversion
INIT_FCALL_BY_NAME into DO_FCALL).
Any thoughts?
Thanks. Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] [RFC] Class instances counter
if a class need that, it can implement a interface like instance_counter,
which will simply can implement like:
class A {
public static $instance_counter = 0;
public function __construct() { self::$instance_counter++; }
public function __destruct() { self::$instance_counter--; };
public static function get_counter() { return self::$instance_counter; }
}
thanks
On Tue, Apr 9, 2013 at 6:18 PM, Frank Liepert frank.liep...@gmx.de wrote:
Hello internals,
I updated the RFC (https://wiki.php.net/rfc/instance_counter):
- added support for a class name, so the function can be narrowed down to a
specific class
- added use case
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
[PHP-DEV] [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
Hey: bug is described at #64554 I proposal to add a leading backslash to all classnames (not only ns names, since no harm, consistent and make sense) when doing serialize, var_export etc. what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Hey: I have to say, the objections only shows up after it happens.. but yes, I am a little rush at this commit, that is because, you can see, the test script in ext/standard/tests/stream is depends on a ugly trick to skip . it make me very uncomfortable. I send the mail the day before yesterday, and it's really not a big change (add a constant), then no new feedback in a day, I think it's okey to commit. however, you are right, it's not a long time, so if objections becomes strong, I can revert it. thanks Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 3, 2013 at 10:42 PM, Kalle Sommer Nielsen ka...@php.net wrote: 2013/4/3 Laruence larue...@php.net: On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 I must say the process of how it was done was not very good. Not only there were no substantial discussion on adding this new thing in stable version before the commit, the time between message announcing it and asking if there are any objections and the commit was barely a day. It's not enough time at all to solicit feedback, and this change is not really something urgent that needs to be committed ASAP. And it turns out, there *are* objections. Could we be a little less quick with commits into a stable version and give it some time when we're talking about new things and not bugfixes? Hey: I have to say, the objections only shows up after it happens.. but yes, I am a little rush at this commit, that is because, you can see, the test script in ext/standard/tests/stream is depends on a ugly trick to skip . it make me very uncomfortable. I send the mail the day before yesterday, and it's really not a big change (add a constant), then no new feedback in a day, I think it's okey to commit. however, you are right, it's not a long time, so if objections becomes strong, I can revert it. I think my argument against adding the constant is at least just as strong as adding it. I agree we shouldn't go RFC/vote etc, over one single constant but I think we can all agree on the fact that we shouldn't try to add hacks to fix usage of an experimental feature (which is essentially what this constant is). Hey: but as you see, many people was entrapped by the experimental feature, and whether the experimental is there is out of their hands. I, from a user aspect, I need to know whether my project can run in the host environment. if not, I can warn the user to re-configure it. this is very important. now, the hack way , as you can see, to check if the --with-curlwrappers exists in phpinfo(), doesn't work very well, if the curl extension is built as shared and separated. I don't think adding this flag is a hack way, it's just to reflect some features, like if (class_exists(PDO)), or like (if PHP_VERSION == 5.4)... thanks We need more consistency, than inconsistencies. -- regards, Kalle Sommer Nielsen ka...@php.net -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Thu, Apr 4, 2013 at 5:37 AM, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
On Wed, Apr 3, 2013 at 2:00 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
There is absolutely no need for a RFC for it.
Heck, even that initial curtesy mail was more then I would have
expected.
Agree, no need for full scale RFC for one constant. However, sending an
email to the list and actually waiting for feedback is exactly what I
would expect, especially dealing with stable version and feature that it
is not exactly clear what's going on with it. We're not talking about
writing RFCs for every minor change, we're talking about teamwork and
have members of the team be aware of the change and have time to discuss
it if needed. Nothing bad would happen if the same commit would land a
week later, after everybody is behind it and every detail is hashed out
(or not if turns out it is out of consensus). The point here is not to
impede work but to support teamwork.
There is a thin line between impeding work and team work for such a
trivial change.
This constant is actually really useful.
The entire feature is however unfortunately broken, but had it been in
a working shape then common. Really? Send an email and wait a week
before being able to write a testcase?
Anyway. Lets move on.
I suspect removing an experimental feature in an extension that is
disabled by default and requires external library still requires an
RFC?
And according to the current rules of the game it cannot be removed in
5.5.1, but has to be removed in 5.6.0?
Hey:
I am afraid yes, we can only remove it in 5.6.
now, since I already commit it (I am sorry for rushing then).
and you all agree that the constant is useful, so I think it's okey to
change the constant's name from curl_wrappers_enable
to curl_wrappers_enabled, and only defined when curl is built with
--with-curlwrappers.
then user can simply use if (defined(CURL_WRAPPERS_ENABLED) {}
after this, we can move on to write a RFC about remove the experiment
feature in 5.6, okey?
thanks
-Hannes
--
Laruence Xinchen Hui
http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Thu, Apr 4, 2013 at 1:39 PM, Levi Morrison morrison.l...@gmail.comwrote: Did I just read that even though we have reasons to believe this is not a good addition that we are *still* going to launch 5.5 with it? where did you read that(not a good addition)? thanks -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
Added new constant CURL_WRAPPERS_ENABLE in (include 5.4) https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7 thanks On Mon, Apr 1, 2013 at 9:53 PM, Laruence larue...@php.net wrote: On Mon, Apr 1, 2013 at 7:18 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Mar 31, 2013 at 6:25 AM, Laruence larue...@php.net wrote: Hey: there are some issues when people run some codes in a php which is compiled with --with-curlwrappers, like #61336, or the recently test script for #64433 (failed when curl wrappers enabled). I know, that the curl wrapper should act the same as php http wrapper, but for now, we need to provide the ability to user, that they can warn if they codes can not run with curl wrappers.. here are some really usages: https://github.com/UnionOfRAD/lithium/issues/59 and http://weizhifeng.net/wrong-with-curlwrappers.html I propose to add a constant : bool CURL_WRAPPERS_ENABLE The curl wrappers have always been a major pain, with plenty of bugs and we tend to forget to add context options there to match the standard wrapper on new feature. It has been marked as experimental since forever, and I think its time to face the failed experiment and remove it. Hey: remove is also okey for me, but, I think it probably can only happen in 5.6 before that, I think a flag to 5.4+ is a good choice :) thanks -Hannes -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Mon, Apr 1, 2013 at 7:18 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Mar 31, 2013 at 6:25 AM, Laruence larue...@php.net wrote: Hey: there are some issues when people run some codes in a php which is compiled with --with-curlwrappers, like #61336, or the recently test script for #64433 (failed when curl wrappers enabled). I know, that the curl wrapper should act the same as php http wrapper, but for now, we need to provide the ability to user, that they can warn if they codes can not run with curl wrappers.. here are some really usages: https://github.com/UnionOfRAD/lithium/issues/59 and http://weizhifeng.net/wrong-with-curlwrappers.html I propose to add a constant : bool CURL_WRAPPERS_ENABLE The curl wrappers have always been a major pain, with plenty of bugs and we tend to forget to add context options there to match the standard wrapper on new feature. It has been marked as experimental since forever, and I think its time to face the failed experiment and remove it. Hey: remove is also okey for me, but, I think it probably can only happen in 5.6 before that, I think a flag to 5.4+ is a good choice :) thanks -Hannes -- Laruence Xinchen Hui http://www.laruence.com/
[PHP-DEV] Add a constant to reflect --with-curlwrappers
Hey: there are some issues when people run some codes in a php which is compiled with --with-curlwrappers, like #61336, or the recently test script for #64433 (failed when curl wrappers enabled). I know, that the curl wrapper should act the same as php http wrapper, but for now, we need to provide the ability to user, that they can warn if they codes can not run with curl wrappers.. here are some really usages: https://github.com/UnionOfRAD/lithium/issues/59 and http://weizhifeng.net/wrong-with-curlwrappers.html I propose to add a constant : bool CURL_WRAPPERS_ENABLE or, any other better name... objections? thanks -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
On Mon, Mar 25, 2013 at 2:42 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, We are going to release a new PECL version today or tomorrow, oh? okey, after you taged, I will do it. :) thanks and, yes, we are going to support hte pecl build for old versions as well. I'm not sure about php-5.2 and possible new features. Thanks. Dmitry. On Sun, Mar 24, 2013 at 12:54 PM, Pierre Joye pierre@gmail.com wrote: On Mar 24, 2013 2:25 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Would it be an idea to put several flavours of php_opcache.dll at http://windows.php.net/downloads/pecl/snaps/ These are quite 'old': http://windows.php.net/downloads/pecl/snaps/ZendOptimizerPlus/7.0.1-dev/ See the requests for such dll's at http://www.apachelounge.com/viewtopic.php?t=5242#24199 Yes, but it should be done using the pecl version, not the version in code. I did not follow the github's repository but as far as I can see none of the fixes in core has been back ported. If I am not mistaken the plan was to have the bundled version 5.5+ only (or for the given branch), and not to keep compatibility with older php versions. Dmitry, what do you think to try to keep releases via pecl and core in sync as long as it is possible? That means one/two years for 5.3, and 3-4 years for 5.4. Cheers, -- Pierre @pierrejoye -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Tue, Mar 26, 2013 at 4:43 AM, Christopher Jones christopher.jo...@oracle.com wrote: On 03/25/2013 08:41 AM, Remi Collet wrote: Le 25/03/2013 06:47, Laruence a écrit : attached here: https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build_2.patchrevision=latest Tested under RHEL 6.4 (bison 2.4.1), Fedora 17 (bison 2.5) and Fedora 18 (bison 2.6.1). NTS and ZTS build OK. Thanks, Remi. Bison 2.3 with Oracle Linux 5.9 (and therefore with RHEL 5.9) gives this error: /home/cjones/php-5.5/Zend/zend_language_parser.y:50.1-5: invalid directive: `%code' /home/cjones/php-5.5/Zend/zend_language_parser.y:50.7-14: syntax error, unexpected identifier Hey, it's weird, I have tested with bison 2.3 (cents), it works fine.. version: bison (GNU Bison) 2.3 thanks [You can get Oracle Linux (and keep up to date with patches and security errata) from http://public-yum.oracle.com/] Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Mon, Mar 25, 2013 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 10:35 AM, Felipe Pena wrote:
Hi,
2013/3/24 Rasmus Lerdorf ras...@lerdorf.com:
On 03/22/2013 02:02 AM, Remi Collet wrote:
While build of 5.5 snapshot works perfectly, beta1 ZTS build is broken
In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here
Comparing the 201303201430 snapshot (very closed to beta1) and beta1
archive
201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. */
beta1:
/* A Bison parser, made by GNU Bison 2.6.1. */
So, it seems snapshot script don't use the same environment than the one
used to generate release.
Any idea how to fix this ?
I took a quick look at this. The Bison change causing this from their
NEWS file is:
*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.
I was hoping the fix would be as simple as doing:
-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }
but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little light
reading and report back it would be appreciated.
http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function
This page explain how to use it.
Sure, I see how they work, but the problem is that they can't be inside
the %{ ... %} code block there. They have to be outside and as such
won't have access to the #ifdef ZTS. So I don't think we can
conditionally create a reentrant parser like we did before without
refactoring things a bit.
if %parse-param defined, then the paramenter also is added to yyerror,
yydestroctor etc.
it will a little big change.
thanks
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Mon, Mar 25, 2013 at 12:42 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 09:30 PM, Laruence wrote:
On Mon, Mar 25, 2013 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 10:35 AM, Felipe Pena wrote:
Hi,
2013/3/24 Rasmus Lerdorf ras...@lerdorf.com:
On 03/22/2013 02:02 AM, Remi Collet wrote:
While build of 5.5 snapshot works perfectly, beta1 ZTS build is broken
In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here
Comparing the 201303201430 snapshot (very closed to beta1) and beta1
archive
201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. */
beta1:
/* A Bison parser, made by GNU Bison 2.6.1. */
So, it seems snapshot script don't use the same environment than the one
used to generate release.
Any idea how to fix this ?
I took a quick look at this. The Bison change causing this from their
NEWS file is:
*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.
I was hoping the fix would be as simple as doing:
-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }
but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little light
reading and report back it would be appreciated.
http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function
This page explain how to use it.
Sure, I see how they work, but the problem is that they can't be inside
the %{ ... %} code block there. They have to be outside and as such
won't have access to the #ifdef ZTS. So I don't think we can
conditionally create a reentrant parser like we did before without
refactoring things a bit.
if %parse-param defined, then the paramenter also is added to yyerror,
yydestroctor etc.
it will a little big change.
Right, but if we handle it like we do with TSRMLS_C throughout the code
and always set that %parse-param to this new magic macro we make up and
have it point to void *compiler_globals for zendparse() under ZTS mode
and void otherwise and make sure it is (re)defined correctly in other
places? It might mean we need to refactor zenderror() to take a dummy
first arg since it seems to prepend the parse-param type there. Messy.
Hmm, seems fine, a patch is attached:
https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build.patchrevision=latest
but there must be some unused parameter term_ls while in non-zts build...
thanks
-Rasmus
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Mon, Mar 25, 2013 at 1:18 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 12:42 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 09:30 PM, Laruence wrote:
On Mon, Mar 25, 2013 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 10:35 AM, Felipe Pena wrote:
Hi,
2013/3/24 Rasmus Lerdorf ras...@lerdorf.com:
On 03/22/2013 02:02 AM, Remi Collet wrote:
While build of 5.5 snapshot works perfectly, beta1 ZTS build is broken
In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here
Comparing the 201303201430 snapshot (very closed to beta1) and beta1
archive
201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. */
beta1:
/* A Bison parser, made by GNU Bison 2.6.1. */
So, it seems snapshot script don't use the same environment than the one
used to generate release.
Any idea how to fix this ?
I took a quick look at this. The Bison change causing this from their
NEWS file is:
*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.
I was hoping the fix would be as simple as doing:
-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }
but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little light
reading and report back it would be appreciated.
http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function
This page explain how to use it.
Sure, I see how they work, but the problem is that they can't be inside
the %{ ... %} code block there. They have to be outside and as such
won't have access to the #ifdef ZTS. So I don't think we can
conditionally create a reentrant parser like we did before without
refactoring things a bit.
if %parse-param defined, then the paramenter also is added to yyerror,
yydestroctor etc.
it will a little big change.
Right, but if we handle it like we do with TSRMLS_C throughout the code
and always set that %parse-param to this new magic macro we make up and
have it point to void *compiler_globals for zendparse() under ZTS mode
and void otherwise and make sure it is (re)defined correctly in other
places? It might mean we need to refactor zenderror() to take a dummy
first arg since it seems to prepend the parse-param type there. Messy.
Hmm, seems fine, a patch is attached:
https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build.patchrevision=latest
but there must be some unused parameter term_ls while in non-zts build...
unused parameter warning I mean, :)
thanks
thanks
-Rasmus
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Mon, Mar 25, 2013 at 1:19 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 1:18 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 12:42 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 09:30 PM, Laruence wrote:
On Mon, Mar 25, 2013 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 10:35 AM, Felipe Pena wrote:
Hi,
2013/3/24 Rasmus Lerdorf ras...@lerdorf.com:
On 03/22/2013 02:02 AM, Remi Collet wrote:
While build of 5.5 snapshot works perfectly, beta1 ZTS build is broken
In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here
Comparing the 201303201430 snapshot (very closed to beta1) and beta1
archive
201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. */
beta1:
/* A Bison parser, made by GNU Bison 2.6.1. */
So, it seems snapshot script don't use the same environment than the
one
used to generate release.
Any idea how to fix this ?
I took a quick look at this. The Bison change causing this from their
NEWS file is:
*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.
I was hoping the fix would be as simple as doing:
-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }
but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little light
reading and report back it would be appreciated.
http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function
This page explain how to use it.
Sure, I see how they work, but the problem is that they can't be inside
the %{ ... %} code block there. They have to be outside and as such
won't have access to the #ifdef ZTS. So I don't think we can
conditionally create a reentrant parser like we did before without
refactoring things a bit.
if %parse-param defined, then the paramenter also is added to yyerror,
yydestroctor etc.
it will a little big change.
Right, but if we handle it like we do with TSRMLS_C throughout the code
and always set that %parse-param to this new magic macro we make up and
have it point to void *compiler_globals for zendparse() under ZTS mode
and void otherwise and make sure it is (re)defined correctly in other
places? It might mean we need to refactor zenderror() to take a dummy
first arg since it seems to prepend the parse-param type there. Messy.
Hmm, seems fine, a patch is attached:
https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build.patchrevision=latest
but there must be some unused parameter term_ls while in non-zts build...
unused parameter warning I mean, :)
hmm, how stupid I was, hehe , simply:
#ifndef ZTS
(void)tsrm_ls;
#endif
:)
thanks
thanks
thanks
-Rasmus
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Mon, Mar 25, 2013 at 1:27 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 10:24 PM, Laruence wrote:
On Mon, Mar 25, 2013 at 1:19 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 1:18 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 12:42 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 03/24/2013 09:30 PM, Laruence wrote:
On Mon, Mar 25, 2013 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 03/24/2013 10:35 AM, Felipe Pena wrote:
Hi,
2013/3/24 Rasmus Lerdorf ras...@lerdorf.com:
On 03/22/2013 02:02 AM, Remi Collet wrote:
While build of 5.5 snapshot works perfectly, beta1 ZTS build is
broken
In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here
Comparing the 201303201430 snapshot (very closed to beta1) and beta1
archive
201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. */
beta1:
/* A Bison parser, made by GNU Bison 2.6.1. */
So, it seems snapshot script don't use the same environment than the
one
used to generate release.
Any idea how to fix this ?
I took a quick look at this. The Bison change causing this from their
NEWS file is:
*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.
I was hoping the fix would be as simple as doing:
-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }
but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little
light
reading and report back it would be appreciated.
http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function
This page explain how to use it.
Sure, I see how they work, but the problem is that they can't be inside
the %{ ... %} code block there. They have to be outside and as such
won't have access to the #ifdef ZTS. So I don't think we can
conditionally create a reentrant parser like we did before without
refactoring things a bit.
if %parse-param defined, then the paramenter also is added to yyerror,
yydestroctor etc.
it will a little big change.
Right, but if we handle it like we do with TSRMLS_C throughout the code
and always set that %parse-param to this new magic macro we make up and
have it point to void *compiler_globals for zendparse() under ZTS mode
and void otherwise and make sure it is (re)defined correctly in other
places? It might mean we need to refactor zenderror() to take a dummy
first arg since it seems to prepend the parse-param type there. Messy.
Hmm, seems fine, a patch is attached:
https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build.patchrevision=latest
but there must be some unused parameter term_ls while in non-zts build...
unused parameter warning I mean, :)
hmm, how stupid I was, hehe , simply:
#ifndef ZTS
(void)tsrm_ls;
#endif
Commit it to master so we can play with it. I think this is the right
approach and we can pull it into 5.5b2. It would be really nice to have
bison 2.6/2.7 support in 5.5.
-Rasmus
Hey:
after a deep look, it seems bison 2.7 still supports
YYPARSE_PARAM, the different is, it starts to write the declaration
of yyparse into parse.h
so, we also needs the YYPARSE_PARAM defination into parse.h.
following patch also works:
diff --git a/Zend/zend_language_parser.y b/Zend/zend_language_parser.y
index ccbc9b1..3424fa7 100644
--- a/Zend/zend_language_parser.y
+++ b/Zend/zend_language_parser.y
@@ -38,16 +38,17 @@
#define YYSIZE_T size_t
#define yytnamerr zend_yytnamerr
static YYSIZE_T zend_yytnamerr(char*, const char*);
-
#define YYERROR_VERBOSE
#define YYSTYPE znode
+
+%}
+
+%code requires {
#ifdef ZTS
# define YYPARSE_PARAM tsrm_ls
# define YYLEX_PARAM tsrm_ls
#endif
-
-
-%}
+}
%pure_parser
%expect 3
could you verify it?
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Mon, Mar 25, 2013 at 1:43 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 1:27 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/24/2013 10:24 PM, Laruence wrote:
On Mon, Mar 25, 2013 at 1:19 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 1:18 PM, Laruence larue...@php.net wrote:
On Mon, Mar 25, 2013 at 12:42 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 03/24/2013 09:30 PM, Laruence wrote:
On Mon, Mar 25, 2013 at 7:38 AM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 03/24/2013 10:35 AM, Felipe Pena wrote:
Hi,
2013/3/24 Rasmus Lerdorf ras...@lerdorf.com:
On 03/22/2013 02:02 AM, Remi Collet wrote:
While build of 5.5 snapshot works perfectly, beta1 ZTS build is
broken
In file included from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:33:0:
/dev/shm/BUILD/php-5.5.0beta1/build-ztscli/Zend/zend_language_parser.h:331:5:
error: conflicting types for 'zendparse'
In file included from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals.h:28:0,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_compile.h:418,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_modules.h:26,
from
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_API.h:26,
from /dev/shm/BUILD/php-5.5.0beta1/main/php.h:38,
from
/dev/shm/BUILD/php-5.5.0beta1/ext/tokenizer/tokenizer.c:25:
/dev/shm/BUILD/php-5.5.0beta1/Zend/zend_globals_macros.h:35:5: note:
previous declaration of 'zendparse' was here
Comparing the 201303201430 snapshot (very closed to beta1) and
beta1 archive
201303201430, in bison generated files:
/* A Bison parser, made by GNU Bison 2.4.1. */
beta1:
/* A Bison parser, made by GNU Bison 2.6.1. */
So, it seems snapshot script don't use the same environment than
the one
used to generate release.
Any idea how to fix this ?
I took a quick look at this. The Bison change causing this from their
NEWS file is:
*** Features deprecated since Bison 1.875
YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of
%parse-param and %lex-param, will no longer be supported.
I was hoping the fix would be as simple as doing:
-#define YYPARSE_PARAM tsrm_ls
-#define YYLEX_PARAM tsrm_ls
+%parse-param { tsrm_ls }
+%lex-param { tsrm_ls }
but that doesn't quite do the trick. Need to read up more on how
%parse-param and %lex-param work. If someone wants to do a little
light
reading and report back it would be appreciated.
http://www.gnu.org/software/bison/manual/html_node/Parser-Function.html#Parser-Function
This page explain how to use it.
Sure, I see how they work, but the problem is that they can't be inside
the %{ ... %} code block there. They have to be outside and as such
won't have access to the #ifdef ZTS. So I don't think we can
conditionally create a reentrant parser like we did before without
refactoring things a bit.
if %parse-param defined, then the paramenter also is added to yyerror,
yydestroctor etc.
it will a little big change.
Right, but if we handle it like we do with TSRMLS_C throughout the code
and always set that %parse-param to this new magic macro we make up and
have it point to void *compiler_globals for zendparse() under ZTS mode
and void otherwise and make sure it is (re)defined correctly in other
places? It might mean we need to refactor zenderror() to take a dummy
first arg since it seems to prepend the parse-param type there. Messy.
Hmm, seems fine, a patch is attached:
https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build.patchrevision=latest
but there must be some unused parameter term_ls while in non-zts build...
unused parameter warning I mean, :)
hmm, how stupid I was, hehe , simply:
#ifndef ZTS
(void)tsrm_ls;
#endif
Commit it to master so we can play with it. I think this is the right
approach and we can pull it into 5.5b2. It would be really nice to have
bison 2.6/2.7 support in 5.5.
-Rasmus
Hey:
after a deep look, it seems bison 2.7 still supports
YYPARSE_PARAM, the different is, it starts to write the declaration
of yyparse into parse.h
so, we also needs the YYPARSE_PARAM defination into parse.h.
following patch also works:
attached here:
https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build_2.patchrevision=latest
thanks
diff --git a/Zend/zend_language_parser.y b/Zend/zend_language_parser.y
index ccbc9b1..3424fa7 100644
--- a/Zend/zend_language_parser.y
+++ b/Zend/zend_language_parser.y
@@ -38,16 +38,17 @@
#define YYSIZE_T size_t
#define yytnamerr zend_yytnamerr
static YYSIZE_T zend_yytnamerr(char*, const char*);
-
#define YYERROR_VERBOSE
#define YYSTYPE znode
+
+%}
+
+%code requires {
#ifdef ZTS
# define YYPARSE_PARAM tsrm_ls
# define YYLEX_PARAM tsrm_ls
#endif
-
-
-%}
+}
%pure_parser
%expect 3
could you verify it?
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence
Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
On Sat, Mar 23, 2013 at 6:31 PM, Terry Ellison te...@ellisons.org.uk wrote: On 23/03/13 09:46, Matīss Roberts Treinis wrote: Memcached is distributed caching system, where as APC's user data cache is not. Memcached requires separate server instance (memcached) to operate. APC does not. Yes, but there is nothing to stop an admin of an application-dedicated system or VM configuring and using an in-server memcached. Also, APC's user cache is 5+ times faster than memcached. If some extension is to provide this functionality, it has to be as close as possible in possibilities and speed as APC's implementation has. Memcached is not and never hasn't been an alternative for APC, they are meant for two different jobs. I also agree that memcache is slower because it is out of process and that for some usecases the relative speed differences due to these context switches will impact application performance. Yes, they have different sweet-spots and operational characteristics, but for many usecases the relative impact will be immaterial, and memcached can be a perfectly acceptable substitute. Applications which are closely coupled to high APC data cache usage will probably stay with APC for the foreseeable future. Hey: APC is not a pure user data cache, the user data cache of it is a additional function of opcodes cache, that means the implemention is restricted by opcodes cache context. and to be honest, I think user data cache and opcodes cache should be separated into different modules.. Yac is a pure user data cache, doesn't have the restriction which APC has, that is why Yac can be implemented without locks. you can see a big performance improvement compare Yac against APC, http://www.laruence.com/2013/03/18/2846.html (use google translate, if you can not read chinese :)) thanks An SMA-based data cache would be a useful adjunct to O+, so I will be interested in this, but I just don't see this filling a show-stopper gap that must be addressed as a priority. snip Laurence, you are correct that O+ doesn't provide data caching, but what about memcached and the PECL packages that support it? http://pecl.php.net/package/memcache and http://pecl.php.net/package/memcached -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] disable zend_always_inline in debug mode
Hey:
I propose to disable zend_alwasy_inline while build PHP in debug mode.
that could be easier for debuging some bugs..
what do you think?
thanks
simple patch:
diff --git a/Zend/zend.h b/Zend/zend.h
index 40515fb..03bd4e7 100644
--- a/Zend/zend.h
+++ b/Zend/zend.h
@@ -365,7 +365,7 @@ struct _zval_struct {
#define Z_UNSET_ISREF(z) Z_UNSET_ISREF_P((z))
#define Z_SET_ISREF_TO(z, isref) Z_SET_ISREF_TO_P((z), isref)
-#if defined(__GNUC__)
+#if defined(__GNUC__) !ZEND_DEBUG
#if __GNUC__ = 3
#define zend_always_inline inline __attribute__((always_inline))
#define zend_never_inline __attribute__((noinline))
@@ -374,7 +374,7 @@ struct _zval_struct {
#define zend_never_inline
#endif
-#elif defined(_MSC_VER)
+#elif defined(_MSC_VER) !ZEND_DEBUG
#define zend_always_inline __forceinline
#define zend_never_inline
#else
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Thu, Feb 28, 2013 at 2:53 PM, Pierre Joye pierre@gmail.com wrote: On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote: Based on the overwhelming response, the vote is now open J https://wiki.php.net/rfc/optimizerplus Voting ends March 7th. ok, given the total lack of answers, mistakes and misleading wording in the RFC and lack of releases in PECL (which is a pre requise since quite some time to get in core), I'd to vote -1 for now. +1, there should be a option release at PECL, which will give the O+ more feedback and test thanks It will surely won't change anything but I stand to what we discuss. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists
On Tue, Feb 19, 2013 at 8:06 PM, Sara Golemon poll...@php.net wrote: Opening RFC to allow trailing comma in function call argument lists https://wiki.php.net/rfc/trailing-comma-function-args -1 on this. I really don't like this, it look very weird, and the gain is minor. thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 4:03 PM, Zeev Suraski z...@zend.com wrote: All, Following the discussion at the end of last week, I prepared a draft RFC for the inclusion of Optimizer+ in PHP. In parallel we’re in the process of prepping the source code for independent public consumption, which I hope we can be done with by the end of next week, hopefully sooner. Thanks! It's great. however, it's a little not perfect that no ZTS supports. :) https://wiki.php.net/rfc/optimizerplus Comments welcome! Zeev -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 4:21 PM, Zeev Suraski z...@zend.com wrote: One important part missing is the actual compatibility/support of thread safe PHP. I know that Zend mostly care about NTS since quite some time and that worries me a lot to bundle something that is not working well in thread safe mode. I would consider that as a stopping point. I mean, not to stop its inclusion, but to release 5.5.0 with it without optimizer working as good as APC in ts mode. It's mentioned in the RFC - but I think we should be able to (re)add NTS support pretty quickly. Hey: my problem gone. ignore my previous mail thanks Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 29/01/13 09:30, Zeev Suraski wrote: [snip] (My guess is that it will show WP being slower and with a more dramatic improvement.) By the way, I just realized the % gain wasn't all that self-explanatory - it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains vs. plain PHP and vs. APC. It's better now ;-). Thank you for the contribution. It's a great news! Can APC and Optimizer+ work in duo or share some features? If O+ became opensource, I think it can be done by lots contributors.. :) thanks -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZTS - why are you using it?
On Tue, Jan 29, 2013 at 5:03 PM, Zeev Suraski z...@zend.com wrote: I didn’t want to hijack the Optimizer+ thread so I’m creating a new one, based on the apparent level of interest in ZTS. This isn’t an RFC to remove ZTS by any stretch, but I **am** a bit confused about why people are still using ZTS. A bit of background. I started the ZTS project (based on initial work by Shane Caraveo more than a decade ago), and invested countless hours in pushing it all throughout PHP. So I really hold absolutely no grudge against it, quite the contrary… However, many years ago, I came to the conclusion that it was a bit of a lost cause trying to weed out all the thread safety issues from everywhere – and that a simpler, more elegant solution exists in the form of FastCGI. Which brings me to the subject of this mail – why are you using ZTS PHP instead of single threaded PHP? The reasons not to use it are few but fairly major – it’s significantly slower than the non-ZTS PHP, and it’s significantly less robust in the sense that a single bug somewhere can bring down an entire server (or at least a bunch of many different threads). What are your reasons to choose it over FastCGI? Hey: It's not we choose ZTS, it is there are many users run with them (IIS, Apache+workers, and pthreads extension require it) and all PHP extensions supports it, so if O+ doesn't, it feel a little inconsistent. thanks Zeev -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZTS - why are you using it?
On Tue, Jan 29, 2013 at 5:28 PM, Laruence larue...@php.net wrote: On Tue, Jan 29, 2013 at 5:03 PM, Zeev Suraski z...@zend.com wrote: I didn’t want to hijack the Optimizer+ thread so I’m creating a new one, based on the apparent level of interest in ZTS. This isn’t an RFC to remove ZTS by any stretch, but I **am** a bit confused about why people are still using ZTS. A bit of background. I started the ZTS project (based on initial work by Shane Caraveo more than a decade ago), and invested countless hours in pushing it all throughout PHP. So I really hold absolutely no grudge against it, quite the contrary… However, many years ago, I came to the conclusion that it was a bit of a lost cause trying to weed out all the thread safety issues from everywhere – and that a simpler, more elegant solution exists in the form of FastCGI. Which brings me to the subject of this mail – why are you using ZTS PHP instead of single threaded PHP? The reasons not to use it are few but fairly major – it’s significantly slower than the non-ZTS PHP, and it’s significantly less robust in the sense that a single bug somewhere can bring down an entire server (or at least a bunch of many different threads). What are your reasons to choose it over FastCGI? Hey: It's not we choose ZTS, it is there are many users run with them (IIS, Apache+workers, and pthreads extension require it) and all PHP extensions supports it, so if O+ doesn't, it feel a little inconsistent. And, if O+ aims only to be a PECL extension, I think it's okey. but if it is going to PHP src, I think the consistent should be considered, agree? thanks thanks Zeev -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZTS - why are you using it?
On Tue, Jan 29, 2013 at 5:35 PM, Zeev Suraski z...@zend.com wrote: Hey: It's not we choose ZTS, it is there are many users run with them (IIS, Apache+workers, and pthreads extension require it) For pthreads I can understand it, but why would users be using it on IIS/Apache instead of using FastCGI? FastCGI is both faster and more robust. Is it a matter of lack of knowledge, or is there a real reason to use it? and all PHP extensions supports it, so if O+ doesn't, it feel a little inconsistent. My question was outside the context of O+ - it should support it for as long as ZTS is available... Oh, in that case, I prefer fcgi(eg: nginx fpm) too. :) thanks Zeev -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: com php-src: Fixed bug #64007 (There is an ability to create instance of Generator by hand).: NEWS ext/reflection/php_reflection.c ext/reflection/tests/bug64007.phpt
On Tue, Jan 22, 2013 at 4:21 PM, David Soria Parra d...@php.net wrote: On 2013-01-19, Xinchen Hui larue...@php.net wrote: Commit:f7b99c481d0a943d922e99ad9afa82c45193030e Author:Xinchen Hui larue...@php.net Sat, 19 Jan 2013 17:01:57 +0800 Parents: e23fca8910b96f1c3bb26c6582c17c92fd6f2f7a Branches: PHP-5.5 Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=f7b99c481d0a943d922e99ad9afa82c45193030e Log: Fixed bug #64007 (There is an ability to create instance of Generator by hand). Use get_constrctor instead of access of the ce-constructor directly please note that this breaks ext/pdo/tests/pdo_036.phpt on the 5.5 branch. Please take a look! Hey: fixed thanks :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][vote] 5.3 EOL
On Mon, Jan 14, 2013 at 5:11 PM, Pierre Joye pierre@gmail.com wrote: hi, I opened the voting phase for the 5.3 EOL RFC. where is the voting page? :) thanks I also changed the polls to reduce confusion between the announce and the actual EOL, to avoid equal results between many options. Thanks for your upcoming votes and let focus and 5.5+ asap :) 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Passing process handles to proc_open and co
On Thu, Dec 6, 2012 at 5:52 PM, Pierre Joye pierre@gmail.com wrote: I mean bug #44942. Sorry. Also to clarify for non C devs. A handle could be an opened file, a pipe or similar resources. Also important to keep in mind that users have to pass their own streams to proc_open if they like to pass or receive data. Hey, but extension should has ability to change the behavior, thinking of pcntl ext thanks On Thu, Dec 6, 2012 at 9:49 AM, Pierre Joye pierre@gmail.com wrote: hi! While looking at the bug #63073, I was wondering if we could simply do not pass open handles to the newly created child process. The main issue in this bug is the session related handles. They are passed to the parent process, which hangs until their are closed. It indeed does not happen (usually) until the end of the request. It makes these functions almost unusable as soon as sessions are used. These functions are about calling external commands and I fail to see which usage may require to access PHP related handles. Does anyone see any issue by not passing them anymore? And fixing this bug (and a couple of other I think)? It is windows only. Not sure if we do the same on other platforms. Cheers, -- Pierre @pierrejoye -- 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Passing process handles to proc_open and co
On Thu, Dec 6, 2012 at 7:02 PM, Laruence larue...@php.net wrote: On Thu, Dec 6, 2012 at 5:52 PM, Pierre Joye pierre@gmail.com wrote: I mean bug #44942. Sorry. Also to clarify for non C devs. A handle could be an opened file, a pipe or similar resources. Also important to keep in mind that users have to pass their own streams to proc_open if they like to pass or receive data. Hey, but extension should has ability to change the behavior, thinking of pcntl ext ignore me, I mis-understood. thanks thanks On Thu, Dec 6, 2012 at 9:49 AM, Pierre Joye pierre@gmail.com wrote: hi! While looking at the bug #63073, I was wondering if we could simply do not pass open handles to the newly created child process. The main issue in this bug is the session related handles. They are passed to the parent process, which hangs until their are closed. It indeed does not happen (usually) until the end of the request. It makes these functions almost unusable as soon as sessions are used. These functions are about calling external commands and I fail to see which usage may require to access PHP related handles. Does anyone see any issue by not passing them anymore? And fixing this bug (and a couple of other I think)? It is windows only. Not sure if we do the same on other platforms. Cheers, -- Pierre @pierrejoye -- 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Hey: sorry for top reply. but how about, move mysql to PECL instead of a E_DEPRECATED? thanks On Fri, Nov 16, 2012 at 2:30 PM, Johannes Schlüter johan...@schlueters.de wrote: On Nov 16, 2012, at 3:16, David Muir davidkm...@gmail.com wrote: The point is, an extension should never be throwing deprecation warnings for a planned migration to PECL. We should warn, when we can. There is a reason that we have PHP_DEP_FE in the source as a feature to mark functions deprecated. (99% of all functions are in extensions) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Expose zend_message_dispatcher_p
Hey: This problem come out when I was figuring a performance issue of Yaf_Loader. Yaf provides a autoloader like PSR0, when doing a classes autoloading. it used to: 1. stat the file, if file does not exists, return 2. zend_compile_file this is okey when you run yaf without opcode cache. but when you run yaf with opcode cache, the first stat syscall become a little waste. since opcode cache always hook the zend_compile_file, and compile the file from cache. so, I changed the autoload to: 1. zend_compile_file 2. if compile failed, then return. but, zend_compile_file will throw warning if the file doesn't exists via zend_message_dispatcher_p so if zend_message_dispatcher_p is ZEND_API, then I can avoid using such mess codes: https://github.com/laruence/php-yaf/blob/master/yaf_loader.c#L377 what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Expose zend_message_dispatcher_p
On Wed, Nov 21, 2012 at 2:35 PM, Dmitry Stogov dmi...@zend.com wrote: [see below] On Wed, Nov 21, 2012 at 6:39 AM, Laruence larue...@php.net wrote: Hey: This problem come out when I was figuring a performance issue of Yaf_Loader. Yaf provides a autoloader like PSR0, when doing a classes autoloading. it used to: 1. stat the file, if file does not exists, return 2. zend_compile_file this is okey when you run yaf without opcode cache. but when you run yaf with opcode cache, the first stat syscall become a little waste. You should just use virtual_realpath() or tsrm_realpath() instead of stat(). They must utilise realpath cache and avoid stat() calls. Hey: Thanks, Dmitry, actually, I didn't do like that is because by default, realpath cache has 2min ttl. but, after a second think, I think this will be better than my current tricky implementation.. I will try in this way :) thanks Thanks. Dmitry. since opcode cache always hook the zend_compile_file, and compile the file from cache. so, I changed the autoload to: 1. zend_compile_file 2. if compile failed, then return. but, zend_compile_file will throw warning if the file doesn't exists via zend_message_dispatcher_p so if zend_message_dispatcher_p is ZEND_API, then I can avoid using such mess codes: https://github.com/laruence/php-yaf/blob/master/yaf_loader.c#L377 what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] git push failed
Hey: is there any change to git box recently? I got a fail message like: Total 5 (delta 3), reused 0 (delta 0) remote: Shared object libvpx.so.0 not found, required by phpTo g...@git.php.net:php-src.git thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git push failed
On Mon, Oct 29, 2012 at 9:16 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/29/2012 12:20 AM, Laruence wrote: Hey: is there any change to git box recently? I got a fail message like: Total 5 (delta 3), reused 0 (delta 0) remote: Shared object libvpx.so.0 not found, required by phpTo g...@git.php.net:php-src.git This is fixed now. hey: great, thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warning when using session_regenerate_id(TRUE) with a SessionHandler
Hey: could you please open a bug at bugs.php.net for that? thanks On Sun, Oct 28, 2012 at 11:05 AM, dabo avatar2004-...@yahoo.fr wrote: Hi folks, I believe there's an issue with the SessionHandler implementation and the way the destroy handler is invoked when using session_regenerate_id(TRUE) Using latest stable Gentoo PHP 5.4.6 but as far as I could tell the C code source for this part hasn't since been touched up to master. The following code generates a warning : $handler = new SessionHandler(); session_set_save_handler($handler, TRUE); // or FALSE, doesn't matter session_start(); session_regenerate_id(TRUE); //session_write_close(); --- PHP Warning: Unknown: Parent session handler is not open in Unknown on line 0 The call to session_write_close() just adds a proper backtrace. The problem seems to come from using the global mod_user_is_open in the PS_SANITY_CHECK_IS_OPEN macro (in ext/session/mod_user_class.c). Any reason session_status isn't checked instead ? Can anyone confirm ? Thank you -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Please do not call zval_dtor on recursive array
Hey: recently we found a problem, that is usage zval_dtor on a recursive array while gc enabled has chance to result a segfault. a reproduce script could be found here: https://github.com/php/php-src/blob/8bd5e15ff7a57791956c4017ee8fb4a8ac0d8d2e/ext/pcre/tests/bug63055.phpt the preg_match used to call zval_dtor on the third argument. which result a segfault, reported at #63055 the segfault backtrace will looks like: http://pastebin.com/uPWBgrTZ thanks to dmitry, we got a simple solution, that is: instead of directly call to zval_dtor, please use following codes instead: zval garbage = *subpats; array_init(subpats); zval_dtor(garbage); thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please do not call zval_dtor on recursive array
On Thu, Oct 18, 2012 at 6:45 PM, Pierre Joye pierre@gmail.com wrote:
hi Dmitry, Laruence!
On Thu, Oct 18, 2012 at 11:46 AM, Laruence larue...@php.net wrote:
Hey:
recently we found a problem, that is usage zval_dtor on a recursive
array while gc enabled has chance to result a segfault.
a reproduce script could be found here:
https://github.com/php/php-src/blob/8bd5e15ff7a57791956c4017ee8fb4a8ac0d8d2e/ext/pcre/tests/bug63055.phpt
the preg_match used to call zval_dtor on the third argument. which
result a segfault, reported at #63055
the segfault backtrace will looks like: http://pastebin.com/uPWBgrTZ
thanks to dmitry, we got a simple solution, that is: instead of
directly call to zval_dtor, please use following codes instead:
zval garbage = *subpats;
array_init(subpats);
zval_dtor(garbage);
Nice catch!
We could add a macro? As it looks like many will forget to do that :)
maybe a seris macro:
ZVAL_REPLACE_LONG()
ZVAL_REPLACE_STRING{L}()
ZVAL_REPLACE_ZVAL()
etc;
thanks , will do it later, only for trunk I think
thanks
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please do not call zval_dtor on recursive array
Hi:
it's great, I tested, and committed. :)
thanks
On Thu, Oct 18, 2012 at 7:19 PM, Dmitry Stogov dmi...@zend.com wrote:
I think, I've found a more simple fix (attached) that don't require
extension patching and even allow to optimize ZE a bit.
Laruence, can you please verify it.
Sorry, I'm quite busy with other tasks.
Thanks. Dmitry.
On 10/18/2012 02:56 PM, Laruence wrote:
On Thu, Oct 18, 2012 at 6:45 PM, Pierre Joye pierre@gmail.com wrote:
hi Dmitry, Laruence!
On Thu, Oct 18, 2012 at 11:46 AM, Laruence larue...@php.net wrote:
Hey:
recently we found a problem, that is usage zval_dtor on a recursive
array while gc enabled has chance to result a segfault.
a reproduce script could be found here:
https://github.com/php/php-src/blob/8bd5e15ff7a57791956c4017ee8fb4a8ac0d8d2e/ext/pcre/tests/bug63055.phpt
the preg_match used to call zval_dtor on the third argument. which
result a segfault, reported at #63055
the segfault backtrace will looks like: http://pastebin.com/uPWBgrTZ
thanks to dmitry, we got a simple solution, that is: instead of
directly call to zval_dtor, please use following codes instead:
zval garbage = *subpats;
array_init(subpats);
zval_dtor(garbage);
Nice catch!
We could add a macro? As it looks like many will forget to do that :)
maybe a seris macro:
ZVAL_REPLACE_LONG()
ZVAL_REPLACE_STRING{L}()
ZVAL_REPLACE_ZVAL()
etc;
thanks , will do it later, only for trunk I think
thanks
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Foreach list behaviour
On Mon, Sep 3, 2012 at 4:20 PM, Derick Rethans der...@php.net wrote: On Mon, 3 Sep 2012, Laruence wrote: On Mon, Sep 3, 2012 at 7:07 AM, Jared Williams jared.willi...@ntlworld.com wrote: Just looking at the foreach list behaviour and it does this... $i = [1, 2, 3]; foreach($i as list($a, $b)) var_dump($a, $b); Outputs NULL NULL NULL NULL NULL NULL There is no test I can see covering this, so cannot tell if its expected. To me, $i does not meet the expected format, so should be some sort of error happening. this is expected behavior, like: ?php list($a, $b) = 1; var_dump($a); Ew, that's quite nasty (in both cases). Is there a way how we could turn those into a notice or so? Hi: yeah, we can trigger a notice if the container is not a array. but maybe deserve a RFC? thanks cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Foreach list behaviour
On Mon, Sep 3, 2012 at 5:28 PM, Pierre Joye pierre@gmail.com wrote: hi, On Mon, Sep 3, 2012 at 10:36 AM, Laruence larue...@php.net wrote: On Mon, Sep 3, 2012 at 4:20 PM, Derick Rethans der...@php.net wrote: On Mon, 3 Sep 2012, Laruence wrote: On Mon, Sep 3, 2012 at 7:07 AM, Jared Williams jared.willi...@ntlworld.com wrote: Just looking at the foreach list behaviour and it does this... $i = [1, 2, 3]; foreach($i as list($a, $b)) var_dump($a, $b); Outputs NULL NULL NULL NULL NULL NULL There is no test I can see covering this, so cannot tell if its expected. To me, $i does not meet the expected format, so should be some sort of error happening. this is expected behavior, like: ?php list($a, $b) = 1; var_dump($a); Ew, that's quite nasty (in both cases). Is there a way how we could turn those into a notice or so? Hi: yeah, we can trigger a notice if the container is not a array. but maybe deserve a RFC? I do not think it is necessary. It is an improvement of this newly added feature and list. Hi: if we fixed this, what about following example: ?php $num = NULL; echo $num[xxx]; does this also deserve a notice? thanks Cheers, -- Pierre @pierrejoye -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
