[PHP-DEV] PHP 5.3.33 - FPM not given getallheaders function.
Reference to bug: https://bugs.php.net/bug.php?id=62596 PHP 5.3.33 - FPM not given getallheaders function.PHP 5.3.33 - FPM not given getallheaders function. PHP 5.4.33-1~dotdeb.1 (cli) (built: Sep 19 2014 12:11:25) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies with XCache v3.2.0, Copyright (c) 2005-2014, by mOo with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans with XCache Cacher v3.2.0, Copyright (c) 2005-2014, by mOo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.33 - FPM not given getallheaders function.
On 9 October 2014 10:08, Bradley Weston brad...@legalweb.org.uk wrote: Reference to bug: https://bugs.php.net/bug.php?id=62596 PHP 5.3.33 - FPM not given getallheaders function.PHP 5.3.33 - FPM not given getallheaders function. While this does need to be patched (there is an open PR that needs checking against current sources and merging), 5.3 is long dead, this won't even make it into 5.4 now. Please update your PHP version to something that's maintained if you want access to new features when they become available. Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.33 - FPM not given getallheaders function.
Opps I meant PHP 5.4.33 On 09/10/2014 12:17, Chris Wright wrote: On 9 October 2014 10:08, Bradley Weston brad...@legalweb.org.uk wrote: Reference to bug: https://bugs.php.net/bug.php?id=62596 PHP 5.3.33 - FPM not given getallheaders function.PHP 5.3.33 - FPM not given getallheaders function. While this does need to be patched (there is an open PR that needs checking against current sources and merging), 5.3 is long dead, this won't even make it into 5.4 now. Please update your PHP version to something that's maintained if you want access to new features when they become available. Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c Zen
Hi! Commit:ee5b30fa197046973e813a80dd0b7c67827c0ae1 Author:Nikita Popov ni...@php.net Thu, 9 Oct 2014 13:58:14 +0200 Parents: 43f1c94ddace679cac008b674ef983199a951542 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=ee5b30fa197046973e813a80dd0b7c67827c0ae1 Log: Remove support for classes without class entries get_class_entry must be non-NULL and return non-NULL. I wonder why this feature removal is done without even a note on the internals, let alone any discussion. Have I missed something? -- 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-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c Zen
Hi Stas, we discussed this issue with Nikita on IRC, and didn't find any use cases for objects without ce now. Nor in php neither in pecl. Do you see any problems? Thanks. Dmitry. On Thu, Oct 9, 2014 at 11:15 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Commit:ee5b30fa197046973e813a80dd0b7c67827c0ae1 Author:Nikita Popov ni...@php.net Thu, 9 Oct 2014 13:58:14 +0200 Parents: 43f1c94ddace679cac008b674ef983199a951542 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=ee5b30fa197046973e813a80dd0b7c67827c0ae1 Log: Remove support for classes without class entries get_class_entry must be non-NULL and return non-NULL. I wonder why this feature removal is done without even a note on the internals, let alone any discussion. Have I missed something? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c Zen
Hi! we discussed this issue with Nikita on IRC, and didn't find any use cases for objects without ce now. Nor in php neither in pecl. Do you see any problems? Those were used to create bridge APIs - like Zend's Java bridge (not sure if supported now, probably not, and if it's still uses that), as far as I remember. It may be that PECL does not use it but people have internal extensions that are not published. So deleting a chunk of the API without as much as a note on internals is not really a good idea, I think. IRC discussion is not a public discussion, since most of the people are not present on the IRC and have no idea about anything being discussed there. -- 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-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c Zen
Yeah, JavaBridge used it, but it doesn't means it need it.
zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
{
return java_class;
}
I agree, it would be better if we would discuss it on @internals, but it
would take much longer time
If you still see use cases for it, please show
Thanks. Dmitry.
On Thu, Oct 9, 2014 at 11:48 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
we discussed this issue with Nikita on IRC, and didn't find any use
cases for objects without ce now.
Nor in php neither in pecl.
Do you see any problems?
Those were used to create bridge APIs - like Zend's Java bridge (not
sure if supported now, probably not, and if it's still uses that), as
far as I remember. It may be that PECL does not use it but people have
internal extensions that are not published. So deleting a chunk of the
API without as much as a note on internals is not really a good idea, I
think.
IRC discussion is not a public discussion, since most of the people are
not present on the IRC and have no idea about anything being discussed
there.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Re: [PHP-DEV] [VOTE] [RFC] Loop + or control structure
On 03/10/2014 22:33, Leigh wrote: Opening the vote on loop + or control structures. https://wiki.php.net/rfc/loop_or Voting will close in 1 week and requires a 2/3 in favour to pass. Remember at this stage the implementation is flexible. Hi, After talking with other members of AFUP, it seems most of us like the idea of having some way of executing code if a loop is never executed. The or keyword feels a bit odd to those who are used to the else of Twig (or other languages) -- but it's not really that much of a problem either: after a while, we'll get used to using or (or some other keyword). So, we would be on the +1 side of things on this. Still, Sara's idea of giving all loop constructs a return value indicating the number of times the loop executed feels great -- and this would probably be more flexible than loop...or I'm guessing this is why you voted no on your own RFC? -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Loop + or control structure
On 9 October 2014 22:20, Pascal Martin, AFUP mail...@pascal-martin.fr wrote: I'm guessing this is why you voted no on your own RFC? Getting this feature working was the result of several compromises, and I didn't like the idea of feeling like I wish this was different, oh wait... it's my fault... every time I used it. It really did boil down to syntactic sugar. There was a small performance gain on large loops compared to using a tracking variable, but it wasn't really enough to overcome my negative feelings towards it. The groundwork and proof of concept patch is there. If someone else knows how to make it sexy, they're free to pick it up and run with it :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c
Hi
On 10 Oct 2014, at 03:57, Dmitry Stogov dmi...@zend.com wrote:
Yeah, JavaBridge used it, but it doesn't means it need it.
zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
{
return java_class;
}
I agree, it would be better if we would discuss it on @internals, but it
would take much longer time
If you still see use cases for it, please show
If anything, could this be recorded in the UPGRADING file?
Thanks
Thanks. Dmitry.
On Thu, Oct 9, 2014 at 11:48 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
we discussed this issue with Nikita on IRC, and didn't find any use
cases for objects without ce now.
Nor in php neither in pecl.
Do you see any problems?
Those were used to create bridge APIs - like Zend's Java bridge (not
sure if supported now, probably not, and if it's still uses that), as
far as I remember. It may be that PECL does not use it but people have
internal extensions that are not published. So deleting a chunk of the
API without as much as a note on internals is not really a good idea, I
think.
IRC discussion is not a public discussion, since most of the people are
not present on the IRC and have no idea about anything being discussed
there.
--
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
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c
Nikita,
please add a few words abut your latest object handlers related changes.
However, I hardly ever expect that people who might use these handlers read
docs :)
Thanks. Dmitry.
On Fri, Oct 10, 2014 at 2:59 AM, Tjerk Meesters tjerk.meest...@gmail.com
wrote:
Hi
On 10 Oct 2014, at 03:57, Dmitry Stogov dmi...@zend.com wrote:
Yeah, JavaBridge used it, but it doesn't means it need it.
zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
{
return java_class;
}
I agree, it would be better if we would discuss it on @internals, but it
would take much longer time
If you still see use cases for it, please show
If anything, could this be recorded in the UPGRADING file?
Thanks
Thanks. Dmitry.
On Thu, Oct 9, 2014 at 11:48 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
we discussed this issue with Nikita on IRC, and didn't find any use
cases for objects without ce now.
Nor in php neither in pecl.
Do you see any problems?
Those were used to create bridge APIs - like Zend's Java bridge (not
sure if supported now, probably not, and if it's still uses that), as
far as I remember. It may be that PECL does not use it but people have
internal extensions that are not published. So deleting a chunk of the
API without as much as a note on internals is not really a good idea, I
think.
IRC discussion is not a public discussion, since most of the people are
not present on the IRC and have no idea about anything being discussed
there.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
