Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
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
[PHP-DEV] [RFC] pecl_http
Hi PHP internals! I've created an RFC for discussion: Whether it is feasible to add pecl_http v2 to the core. https://wiki.php.net/rfc/pecl_http -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 回复： [PHP-DEV] 回复： [PHP-DEV] How should I call a PHP function
On Tue, 19 Aug 2014, Wei Dai wrote: On Mon, 18 Aug 2014, Wei Dai wrote: I'm trying to call a function inside a module, a PHP_FUNCTION. Other than zend_eval_stringl, what's the direct way to do it? Please refer to call_user_function and call_user_function_ex. Actually, you need to be careful with this. If you are calling another PHP function in the same extension, do *not* use call_user_function. Instead, create a common C function that you can call from whereever you need to. call_user_function(_ex) is not fast. i agree. here is a scenario: i was wrote an extension, and i need to call some PHP function like “strtr (http://lxr.php.net/s?defs=strtrproject=PHP_5_4)” “*trim or a function in another extension but it doesn’t have a common C function. However, i don’t want to copy the implement code into my extension. so, i have two options: 1. copy the duplicate code into my extension, It can be fast in this way, but the code is not beautiful. 2. call call_user_function(_ex) , it’s slower than the first option, but the code is more simple and beautiful than the first option. or: 3. refactor the functionality in PHP so that trim or others *can* be used in extensions. I would not pick option 2, especially not if you're going to call this function a lot. Calling a PHP function directly involves a lot more overhead than just calling a C-function. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 回复： [PHP-DEV] 回复： [PHP-DEV] How should I call a PHP function
On Tue, Aug 19, 2014 at 10:55 AM, Derick Rethans der...@php.net wrote: On Tue, 19 Aug 2014, Wei Dai wrote: On Mon, 18 Aug 2014, Wei Dai wrote: so, i have two options: 1. copy the duplicate code into my extension, It can be fast in this way, but the code is not beautiful. 2. call call_user_function(_ex) , it’s slower than the first option, but the code is more simple and beautiful than the first option. or: 3. refactor the functionality in PHP so that trim or others *can* be used in extensions. Best option, while not possible for existing releases, a good example (trim): http://lxr.php.net/xref/phpng/ext/standard/string.c#784 Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 回复： [PHP-DEV] Re: 回复： [PHP-DEV] 回复： [PHP-DEV] How should I call a PHP function
On Tue, Aug 19, 2014 at 10:55 AM, Derick Rethans der...@php.net (mailto:der...@php.net) wrote: On Tue, 19 Aug 2014, Wei Dai wrote: On Mon, 18 Aug 2014, Wei Dai wrote: so, i have two options: 1. copy the duplicate code into my extension, It can be fast in this way, but the code is not beautiful. 2. call call_user_function(_ex) , it’s slower than the first option, but the code is more simple and beautiful than the first option. or: 3. refactor the functionality in PHP so that trim or others *can* be used in extensions. Best option, while not possible for existing releases, a good example (trim): http://lxr.php.net/xref/phpng/ext/standard/string.c#784 trim is just an example, we can call it 'x'. x is a php function and it doesn't have a common C api.
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
[PHP-DEV] Re: [RFC] pecl_http
Michael Wallner in php.internals (Tue, 19 Aug 2014 09:49:34 +0200): Hi PHP internals! I've created an RFC for discussion: Whether it is feasible to add pecl_http v2 to the core. https://wiki.php.net/rfc/pecl_http Is pecl_http v2 still dependent on propro and raphf? If so, they should be in core as well. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 回复： [PHP-DEV] 回复： [PHP-DEV] How should I call a PHP function
On Tue, Aug 19, 2014 at 11:11 AM, Wei Dai zxcvda...@gmail.com wrote: On Tue, Aug 19, 2014 at 10:55 AM, Derick Rethans der...@php.net wrote: On Tue, 19 Aug 2014, Wei Dai wrote: On Mon, 18 Aug 2014, Wei Dai wrote: so, i have two options: 1. copy the duplicate code into my extension, It can be fast in this way, but the code is not beautiful. 2. call call_user_function(_ex) , it’s slower than the first option, but the code is more simple and beautiful than the first option. or: 3. refactor the functionality in PHP so that trim or others *can* be used in extensions. Best option, while not possible for existing releases, a good example (trim): http://lxr.php.net/xref/phpng/ext/standard/string.c#784 trim is just an example, we can call it 'x'. x is a php function and it doesn't have a common C api. Yes, just pointing you at how it could be done, for functions not exposed as a C API. -- Pierre @pierrejoye | http://www.libgd.org -- 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] Re: [RFC] pecl_http
On Tue, Aug 19, 2014 at 11:17 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Michael Wallner in php.internals (Tue, 19 Aug 2014 09:49:34 +0200): Hi PHP internals! I've created an RFC for discussion: Whether it is feasible to add pecl_http v2 to the core. https://wiki.php.net/rfc/pecl_http Is pecl_http v2 still dependent on propro and raphf? If so, they should be in core as well. I never really understood why they are needed or why they have been splitted off. I can imagine that other exts may need a similar thing but... Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- 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] [VOTE] Abstract Syntax Tree
On Tue, Aug 19, 2014 at 11:30 AM, Laruence larue...@php.net wrote:
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
It does, the result of the expression will be.
But the fix is imo wrong. A size cannot be negative, per se.
It would be cleaner to do:
size_t zend_ast_size(int children) {
if (children 0) {
return sizeof(zend_ast) + sizeof(zend_ast *) * (children - 1);
} else {
// 0 or sizeof(zend_ast) + sizeof(zend_ast *) if at least one
elem is allocated (NULLed).
}
}
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Tue, Aug 19, 2014 at 11:21 AM, Laruence larue...@php.net wrote: Hey: the problem came from zend_ast_size for 0 children node.. Thanks for the report, this should be fixed now: https://github.com/nikic/php-src/commit/69f0deb399eec76bc8afa97fa383b08a207582fb Nikita
[PHP-DEV] 回复： [PHP-DEV] 回复： [PHP-DEV] How should I call a PHP function
On Tue, 19 Aug 2014, Wei Dai wrote: On Mon, 18 Aug 2014, Wei Dai wrote: I'm trying to call a function inside a module, a PHP_FUNCTION. Other than zend_eval_stringl, what's the direct way to do it? Please refer to call_user_function and call_user_function_ex. Actually, you need to be careful with this. If you are calling another PHP function in the same extension, do *not* use call_user_function. Instead, create a common C function that you can call from whereever you need to. call_user_function(_ex) is not fast. i agree. here is a scenario: i was wrote an extension, and i need to call some PHP function like “strtr (http://lxr.php.net/s?defs=strtrproject=PHP_5_4)” “*trim or a function in another extension but it doesn’t have a common C function. However, i don’t want to copy the implement code into my extension. so, i have two options: 1. copy the duplicate code into my extension, It can be fast in this way, but the code is not beautiful. 2. call call_user_function(_ex) , it’s slower than the first option, but the code is more simple and beautiful than the first option. or: 3. refactor the functionality in PHP so that trim or others *can* be used in extensions. I would not pick option 2, especially not if you're going to call this function a lot. Calling a PHP function directly involves a lot more overhead than just calling a C-function. you are right. the reason to write php extension, because we can get performance improvement. cheer, Wei Dai
Re: [PHP-DEV] 5.4 security only
I'd like to see https://github.com/php/php-src/pull/694 / https://github.com/php/php-src/pull/765 in so FPM in 5.4 will work properly with Apache 2.4.10+'s mod_proxy_fcgi. David On 19 Aug 2014, at 01:59, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Moving this out of other topics into its own: according to the release RFC, we should have 5.4 have 2 years of bugfixes one year of security fixes. Since 5.4 was released in March 2012, we're already past 2 year mark. However, we're still have some bugfixes in 5.4, so I'd like to do this: - 5.4.32 is released as planned this week, nothing changes there. - 5.4 branch that is to be 5.4.33 will be the last release that has any non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is out too, so that would play nice with the two stable branches, one security branch theme. Starting from that release forward, 5.4 would be purely security fixes only branch. - EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into 5.4 branch unless they are very important ones (and that is only because people may, in theory, have pending patches and we didn't give advance notice). Importance would have to be determined somewhat arbitrarily, but basically if it works without it, then it's not in, if there's serious doubt if it should be in, it's not in, etc. Security issues, of course, still allowed in. This means if somebody has some pending non-security fixes that have to be in 5.4, the following two weeks are the last call, provided that the fixes really must be in 5.4. Any objections/suggested modifications to this plan? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 security only
On Tue, Aug 19, 2014 at 1:59 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Moving this out of other topics into its own: according to the release RFC, we should have 5.4 have 2 years of bugfixes one year of security fixes. Since 5.4 was released in March 2012, we're already past 2 year mark. However, we're still have some bugfixes in 5.4, so I'd like to do this: - 5.4.32 is released as planned this week, nothing changes there. - 5.4 branch that is to be 5.4.33 will be the last release that has any non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is out too, so that would play nice with the two stable branches, one security branch theme. Starting from that release forward, 5.4 would be purely security fixes only branch. - EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into 5.4 branch unless they are very important ones (and that is only because people may, in theory, have pending patches and we didn't give advance notice). Importance would have to be determined somewhat arbitrarily, but basically if it works without it, then it's not in, if there's serious doubt if it should be in, it's not in, etc. Security issues, of course, still allowed in. This means if somebody has some pending non-security fixes that have to be in 5.4, the following two weeks are the last call, provided that the fixes really must be in 5.4. Any objections/suggested modifications to this plan? This seems just right to me. +1 Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] pecl_http
On Tue, 2014-08-19 at 09:49 +0200, Michael Wallner wrote: Hi PHP internals! I've created an RFC for discussion: Whether it is feasible to add pecl_http v2 to the core. https://wiki.php.net/rfc/pecl_http In my opinion when moving this to core the http(s):// stream should use the same HTTP implementation so one has consistent behavior. I also see that HTTP offers Content type guessing [...] by building this extension with libmagic support I think that should based on fileinfo so both report the same type for a file. Again consistency. I also think the HTTP module should be forced on (like SPL or pcre) or at least be on by default (unless --disable-[all|http] is used) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] pecl_http
On 19 August 2014 11:17, Jan Ehrhardt php...@ehrhardt.nl wrote: Is pecl_http v2 still dependent on propro and raphf? If so, they should be in core as well. Yes, they are mentioned in the Open Issues section. -- Regards, Mike
Re: [PHP-DEV] Re: [RFC] pecl_http
On 19 August 2014 11:24, Pierre Joye pierre@gmail.com wrote: On Tue, Aug 19, 2014 at 11:17 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Is pecl_http v2 still dependent on propro and raphf? If so, they should be in core as well. I never really understood why they are needed or why they have been splitted off. I can imagine that other exts may need a similar thing but... To be reusable. pecl/raphf is also used by pecl/pq; peck/propro has not had another use case yet, though. -- Regards, Mike
Re: [PHP-DEV] [RFC] pecl_http
On 19 August 2014 13:53, Johannes Schlüter johan...@schlueters.de wrote: In my opinion when moving this to core the http(s):// stream should use the same HTTP implementation so one has consistent behavior. This would add a hard dependency on libcurl, which I'd be obviously fine with. I also see that HTTP offers Content type guessing [...] by building this extension with libmagic support I think that should based on fileinfo so both report the same type for a file. Again consistency. This is from the v1-docs and was developed in a time before Fileinfo existed. That feature was not elevated to v2. I also think the HTTP module should be forced on (like SPL or pcre) or at least be on by default (unless --disable-[all|http] is used) johannes -- Regards, Mike
Re: [PHP-DEV] Re: [RFC] pecl_http
On Tue, Aug 19, 2014 at 2:19 PM, Michael Wallner m...@php.net wrote: On 19 August 2014 11:24, Pierre Joye pierre@gmail.com wrote: On Tue, Aug 19, 2014 at 11:17 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Is pecl_http v2 still dependent on propro and raphf? If so, they should be in core as well. I never really understood why they are needed or why they have been splitted off. I can imagine that other exts may need a similar thing but... To be reusable. pecl/raphf is also used by pecl/pq; peck/propro has not had another use case yet, though. propo could be a spl thing, if usefull for other. As of raphf, not sure, mixed toughts. Maybe as part of main/? I am not sure I like to habe two other extensions for that, they are handy tho' :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 security only
2014.08.19. 1:59 ezt írta (Stas Malyshev smalys...@sugarcrm.com): Hi! Moving this out of other topics into its own: according to the release RFC, we should have 5.4 have 2 years of bugfixes one year of security fixes. Since 5.4 was released in March 2012, we're already past 2 year mark. However, we're still have some bugfixes in 5.4, so I'd like to do this: - 5.4.32 is released as planned this week, nothing changes there. - 5.4 branch that is to be 5.4.33 will be the last release that has any non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is out too, so that would play nice with the two stable branches, one security branch theme. Starting from that release forward, 5.4 would be purely security fixes only branch. - EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into 5.4 branch unless they are very important ones (and that is only because people may, in theory, have pending patches and we didn't give advance notice). Importance would have to be determined somewhat arbitrarily, but basically if it works without it, then it's not in, if there's serious doubt if it should be in, it's not in, etc. Security issues, of course, still allowed in. This means if somebody has some pending non-security fixes that have to be in 5.4, the following two weeks are the last call, provided that the fixes really must be in 5.4. Any objections/suggested modifications to this plan? Nope, I think it is a good plan.
[PHP-DEV] Re: [RFC] pecl_http
On 19/08/14 09:49, Michael Wallner wrote: Hi PHP internals! I've created an RFC for discussion: Whether it is feasible to add pecl_http v2 to the core. https://wiki.php.net/rfc/pecl_http Just a heads up. People seem very confused because they read the docs on php.net and don't bother to actually read the (very short) RFC, so here's a link to the API docs of v2; you're welcome. http://devel-m6w6.rhcloud.com/mdref/http/ -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
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? Thanks. Dmitry.
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
hi, On Tue, Aug 19, 2014 at 4: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? It is mainly a debugging function, self contained, etc... Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
got it. thanks! On Aug 18, 2014, at 11: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
Re: [PHP-DEV] Re: 5.6.0 final is near
Please make sure these security fixes are included: fileinfo: Fixed bug #67716 (Segfault in cdf.c). (CVE-2014-3587) gd: Fixed bug #67730 (Null byte injection possible with imagexxx functions). (CVE-2014-5120) Thanks, Kaplan On Mon, Aug 18, 2014 at 5:46 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Aug 17, 2014 at 11:25 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I'm planning to release 5.6.0 from RC4 if nothing serious comes up, so this is just a heads-up: if you think that there is some fix, which should make into the 5.6.0 final (which isn't in RC4) or if you think that there is some blocker issue which should be solved before the 5.6.0 final release, please drop me an email just to be sure. Thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu Hi, just to clarify: if no blocker issue is reported from php-5.6.0RC4, then we won't have another RC, but php-5.6.0 (final) will be tagged using PHP-5.6.0RC4 as it base, and maybe some commits cherry-picked (security fixes for example, or changes with low impact like NEWS/UPGRADING/test fixes) on top of it. so commits in the PHP-5.6 branch after the RC4 tagging won't be in the final by default, only if you can convince me that we need that. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] [RFC] Integer Semantics
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 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
Re: [PHP-DEV] [RFC] Integer Semantics
On Tue, Aug 19, 2014 at 3:36 PM, 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 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 Makes sense to me. I was a little uneasy at first, but you made a very good point that a high-level language like PHP should be abstracting such environment-dependent differences away. And since you're targetting the next major release, BC isn't an issue. --Kris
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
Re: [PHP-DEV] [RFC] Integer Semantics
On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: https://wiki.php.net/rfc/integer_semantics In a perfect world, I'd rather see -X be equivalent to X, but since we do something very different currently, I think your approach of throw an error and ask questions later seems appropriate. The other ones all sound inarguable. +1 -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/standard/tests/http/bug60570.phpt failure
Anyone objects about it or thinks it needs RFC? Thanks. Dmitry. On Wed, Aug 20, 2014 at 6:48 AM, Laruence larue...@php.net wrote: 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/
Re: [PHP-DEV] [RFC] Integer Semantics
1) INF conversion to zero seems wrong. May be +INF should be converted to MAX_LONG and -INF to MIN_LONG? 2) Negative shifts would be useful, as Sara mentioned. 3) a bit unrelated, but it also may make sense to introduce a logical right shift operator ( in Java) the rest seems fine, patch looks OK. Thanks. Dmitry. On Wed, Aug 20, 2014 at 8:05 AM, Sara Golemon poll...@php.net wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: https://wiki.php.net/rfc/integer_semantics In a perfect world, I'd rather see -X be equivalent to X, but since we do something very different currently, I think your approach of throw an error and ask questions later seems appropriate. The other ones all sound inarguable. +1 -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
