Re: [PHP-DEV] Concurrency support for run-tests
On 7 July 2014 17:17, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Jul 7, 2014 at 3: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? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php for the record, we had a rewrite of run-tests.php which supported parallel execution of the tests: http://git.php.net/?p=phpruntests.git;a=summary docs: https://wiki.php.net/qa/runtests/documentation What's the status of this? Why don't we use it? How about letting travis run it additionally for some time? -- Regards, Mike
Re: [PHP-DEV] Concurrency support for run-tests
On 7 July 2014 19:13, Pierre Joye pierre@gmail.com wrote: On Mon, Jul 7, 2014 at 5:07 PM, Laruence larue...@php.net wrote: 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 sounds too make specific, a simple concurrency argument would do it. Yes, there's a --concurrency switch in run-tests.php About the need of a flag for the tests, it would be useful as well. Many tests can't be in run in parallel, like many mysql tests (or other databases f.e.). Why can't those tests use unique (to them) names? -- Regards, Mike
Re: [PHP-DEV] Concurrency support for run-tests
On Tue, Jul 8, 2014 at 8:02 AM, Michael Wallner m...@php.net wrote: About the need of a flag for the tests, it would be useful as well. Many tests can't be in run in parallel, like many mysql tests (or other databases f.e.). Why can't those tests use unique (to them) names? mysql f.e. initialized a DB, may have initial data as well and tests alter them. The setup scripts may be changed and allows one DB per test but I am not sure it will save much time. However you can try, maybe it is worth it :) -- 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] Implemented fallocate() syscall in streams
Hi Julien, On Fri, June 13, 2014 16:20, Julien Pauli wrote: Hi, I just wrote a patch to add fallocate() syscall support for streams. It relies on posix_fallocate(), so that it should support many Unixes. Linux's got a specification with a fallocate() function, more powerful than the posix call. fallocate() does write blocks to the underlying filesystem (not so many are supported, but the ones not supported should proxy to ftruncate()) and prevents sparse file creation whereas ftruncate() just updates inode information, leading to possible future out of space errors. I got a POC showing the diffs between both calls here : https://gist.github.com/jpauli/8afec7c4fc2b38f8ff27 I propose two APIs for PHP : - One that adds a function : fallocate() https://github.com/jpauli/php-src/tree/fallocate - One that relies on ftruncate() , and adds a bool$use_fallocate flag https://github.com/jpauli/php-src/tree/fallocate_flag Please, note that the latest proposal requires patches in different extensions, as I changed a PHP_API function signature. I don't know if Windows can support that. Pierre, Anatol ? :-) Tests are beeing written at the moment. I didn't implement this is user stream handlers, as this really is a low level implementation design that is kind of useless for usage in user streams. Thoughts ? I've found this code http://hg.mozilla.org/mozilla-central/file/3d846420a907/xpcom/glue/FileUtils.cpp#l61 On windows there's no such syscalls. All the data is however buffered, as usual. An emulation could be of course implemented for Windows and other unsupported platforms. However it probably wouldn't mimic the exact behavior. But besides writing in blocks (fallocate) and fast truncating - there are some other useful things i see on the man page. I mean checking for the free space or all those flags like zeroing file space. Actually, maybe it'd be even more useful to put it into user space, maybe as normal functions? Otherwise, if you think it's too low level, one could go two ways - ether implement an emulation, or just use HAVE_FALLOCATE and a configure switch to activate it manually. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implemented fallocate() syscall in streams
On 8 July 2014 08:42, Anatol Belski anatol@belski.net wrote: Hi Julien, On Fri, June 13, 2014 16:20, Julien Pauli wrote: Hi, I just wrote a patch to add fallocate() syscall support for streams. It relies on posix_fallocate(), so that it should support many Unixes. Linux's got a specification with a fallocate() function, more powerful than the posix call. Nice! I propose two APIs for PHP : - One that adds a function : fallocate() https://github.com/jpauli/php-src/tree/fallocate - One that relies on ftruncate() , and adds a bool$use_fallocate flag https://github.com/jpauli/php-src/tree/fallocate_flag Please, note that the latest proposal requires patches in different extensions, as I changed a PHP_API function signature. I'd prefer the first option. I don't know if Windows can support that. Pierre, Anatol ? :-) Tests are beeing written at the moment. I didn't implement this is user stream handlers, as this really is a low level implementation design that is kind of useless for usage in user streams. Thoughts ? I've found this code http://hg.mozilla.org/mozilla-central/file/3d846420a907/xpcom/glue/FileUtils.cpp#l61 Very good catch! -- Regards, Mike
Re: [PHP-DEV] Implemented fallocate() syscall in streams
On 13/06/2014 16:20, Julien Pauli wrote: Hi, Hello :-), I just wrote a patch to add fallocate() syscall support for streams. It relies on posix_fallocate(), so that it should support many Unixes. Linux's got a specification with a fallocate() function, more powerful than the posix call. fallocate() does write blocks to the underlying filesystem (not so many are supported, but the ones not supported should proxy to ftruncate()) and prevents sparse file creation whereas ftruncate() just updates inode information, leading to possible future out of space errors. I got a POC showing the diffs between both calls here : https://gist.github.com/jpauli/8afec7c4fc2b38f8ff27 I propose two APIs for PHP : - One that adds a function : fallocate() https://github.com/jpauli/php-src/tree/fallocate I prefer this one. - One that relies on ftruncate() , and adds a bool$use_fallocate flag https://github.com/jpauli/php-src/tree/fallocate_flag Please, note that the latest proposal requires patches in different extensions, as I changed a PHP_API function signature. I don't know if Windows can support that. Pierre, Anatol ? :-) Tests are beeing written at the moment. I didn't implement this is user stream handlers, as this really is a low level implementation design that is kind of useless for usage in user streams. Thoughts ? If the first one is used, please, consider exposing it on the user-land of stream wrappers (exemple: `stream_allocate`) if possible. Cheers. -- 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
Re: [PHP-DEV] Implemented fallocate() syscall in streams
On Tue, Jul 8, 2014 at 8:42 AM, Anatol Belski anatol@belski.net wrote: Hi Julien, On Fri, June 13, 2014 16:20, Julien Pauli wrote: Hi, I just wrote a patch to add fallocate() syscall support for streams. It relies on posix_fallocate(), so that it should support many Unixes. Linux's got a specification with a fallocate() function, more powerful than the posix call. fallocate() does write blocks to the underlying filesystem (not so many are supported, but the ones not supported should proxy to ftruncate()) and prevents sparse file creation whereas ftruncate() just updates inode information, leading to possible future out of space errors. I got a POC showing the diffs between both calls here : https://gist.github.com/jpauli/8afec7c4fc2b38f8ff27 I propose two APIs for PHP : - One that adds a function : fallocate() https://github.com/jpauli/php-src/tree/fallocate - One that relies on ftruncate() , and adds a bool$use_fallocate flag https://github.com/jpauli/php-src/tree/fallocate_flag Please, note that the latest proposal requires patches in different extensions, as I changed a PHP_API function signature. I don't know if Windows can support that. Pierre, Anatol ? :-) Tests are beeing written at the moment. I didn't implement this is user stream handlers, as this really is a low level implementation design that is kind of useless for usage in user streams. Thoughts ? I've found this code http://hg.mozilla.org/mozilla-central/file/3d846420a907/xpcom/glue/FileUtils.cpp#l61 On windows there's no such syscalls. All the data is however buffered, as usual. An emulation could be of course implemented for Windows and other unsupported platforms. However it probably wouldn't mimic the exact behavior. But besides writing in blocks (fallocate) and fast truncating - there are some other useful things i see on the man page. I mean checking for the free space or all those flags like zeroing file space. Actually, maybe it'd be even more useful to put it into user space, maybe as normal functions? Otherwise, if you think it's too low level, one could go two ways - ether implement an emulation, or just use HAVE_FALLOCATE and a configure switch to activate it manually. You talk about fallocate() function. My patch is based on posix_fallocate() call, which doesn' implement all those (interesting) flags. fallocate() is Linux only , that's why we can't rely on it and can't publish it in user land. And for Windows, I guess we could write a compat implementation (like the mozilla one), but it anyway won't do the same job Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implemented fallocate() syscall in streams
On Tue, Jul 8, 2014 at 9:37 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 13/06/2014 16:20, Julien Pauli wrote: Hi, Hello :-), I just wrote a patch to add fallocate() syscall support for streams. It relies on posix_fallocate(), so that it should support many Unixes. Linux's got a specification with a fallocate() function, more powerful than the posix call. fallocate() does write blocks to the underlying filesystem (not so many are supported, but the ones not supported should proxy to ftruncate()) and prevents sparse file creation whereas ftruncate() just updates inode information, leading to possible future out of space errors. I got a POC showing the diffs between both calls here : https://gist.github.com/jpauli/8afec7c4fc2b38f8ff27 I propose two APIs for PHP : - One that adds a function : fallocate() https://github.com/jpauli/php-src/tree/fallocate I prefer this one. - One that relies on ftruncate() , and adds a bool$use_fallocate flag https://github.com/jpauli/php-src/tree/fallocate_flag Please, note that the latest proposal requires patches in different extensions, as I changed a PHP_API function signature. I don't know if Windows can support that. Pierre, Anatol ? :-) Tests are beeing written at the moment. I didn't implement this is user stream handlers, as this really is a low level implementation design that is kind of useless for usage in user streams. Thoughts ? If the first one is used, please, consider exposing it on the user-land of stream wrappers (exemple: `stream_allocate`) if possible. I find it very useless as user stream already have the ftruncate exposed to them. The difference between ftruncate and fallocate is meaningless in userland. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Name of Next Release of PHP
On Mon, Jul 7, 2014 at 3:13 PM, Zeev Suraski z...@zend.com wrote: On 7 ביול 2014, at 08:59, Andrea Faulds a...@ajf.me wrote: On 7 Jul 2014, at 13:57, Zeev Suraski z...@zend.com wrote: I don't think it's a problem, because I don't think we're two years away from releasing a phpng-based version and I don't think it's a moving target at this point. So I agree we need to remove these uncertainties. I'm going to start an RFC-based discussion for moving phpng to master so that the uncertainties around it are removed. phpng has mostly been just performance so far, right? Could we use this opportunity, where it is not yet master, to make some deeper improvements? What do you mean by deeper improvements? phpng is focused on performance. We can have other improvements for the next version of PHP, of course... I'd like to start a discussion about IO multiplexing on that subject as well. We could improve lots of performance of both the engine and user scripts. I already started a topic about it on internals, and I should write an RFC about it. I'm also worried about the API of future PHP-Next. php-ng or not, I dont care. What I'd like is a clean API, and well documented, so that it is not as hard to get into code as nowadays. Nowadays its just very hard to put one's head into code when not familiar with it. I want for PHP-Next something clean and documented so that it will be even more open to new minds. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implemented fallocate() syscall in streams
On 08/07/2014 11:08, Julien Pauli wrote: On Tue, Jul 8, 2014 at 9:37 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: On 13/06/2014 16:20, Julien Pauli wrote: - One that relies on ftruncate() , and adds a bool$use_fallocate flag https://github.com/jpauli/php-src/tree/fallocate_flag Please, note that the latest proposal requires patches in different extensions, as I changed a PHP_API function signature. I don't know if Windows can support that. Pierre, Anatol ? :-) Tests are beeing written at the moment. I didn't implement this is user stream handlers, as this really is a low level implementation design that is kind of useless for usage in user streams. Thoughts ? If the first one is used, please, consider exposing it on the user-land of stream wrappers (exemple: `stream_allocate`) if possible. I find it very useless as user stream already have the ftruncate exposed to them. Hum no, this is very useful actually. A stream wrapper can be used to represent a file somewhere else, imagine `ntfs://`, `smb://`, `aws://`, `ftp://`, `afp://` etc. The difference between ftruncate and fallocate is meaningless in userland. If `fallocate` is proposed in the user-land, then it will be logical to have it in the stream wrapper API. That's it :-). -- 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
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
On Mon, 7 Jul 2014, Nikita Popov 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. I've just voted no for this, because it introduces a tiny BC break. Now, I realize this is a tiny BC break, but it is just *those* that drive people nuts when upgrading. There is so much non-public code - a cursor check of Symfony and ZF is not representative. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
On 8 Jul 2014, at 15:48, Derick Rethans der...@php.net wrote: I've just voted no for this, because it introduces a tiny BC break. Now, I realize this is a tiny BC break, but it is just *those* that drive people nuts when upgrading. There is so much non-public code - a cursor check of Symfony and ZF is not representative. It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why not? It’s a tiny change which will bother some people but make everyone else’s life easier. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Uniform Variable Syntax
On 8 Jul 2014, at 15:48, Derick Rethans der...@php.net wrote: I've just voted no for this, because it introduces a tiny BC break. Now, I realize this is a tiny BC break, but it is just *those* that drive people nuts when upgrading. There is so much non-public code - a cursor check of Symfony and ZF is not representative. From Andrea Faulds: It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why not? It’s a tiny change which will bother some people but make everyone else’s life easier. Thank you, Derick, for voting against a BC break. I do appreciate the intention of making things more consistent. Given that this is a parser change, I wonder if there is hope of mitigating the BC issues by providing an option to generate new code from old code. Today, I can run php -l and php will tell me about syntax problems. If php6 had a php --convert-from 5.4.30 that would read in a file that worked in 5.4.30 and output a file that does the same thing using php6 syntax, I think that would be a Good Thing. Perhaps it would be better as a tool on the side than as part of the main php executable. I know such a conversion process is effectively impossible for some BC breaks; I don't know about this one. This RFC struck me as a better candidate than usual. Thanks for your consideration. - Todd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Uniform Variable Syntax
On 8 Jul 2014, at 16:41, Todd Ruth tr...@proposaltech.com wrote: Given that this is a parser change, I wonder if there is hope of mitigating the BC issues by providing an option to generate new code from old code. Today, I can run php -l and php will tell me about syntax problems. If php6 had a php --convert-from 5.4.30 that would read in a file that worked in 5.4.30 and output a file that does the same thing using php6 syntax, I think that would be a Good Thing. Perhaps it would be better as a tool on the side than as part of the main php executable. I know such a conversion process is effectively impossible for some BC breaks; I don't know about this one. This RFC struck me as a better candidate than usual. For PHP 6, we could probably make a 2to3-style tool (2to3 is a utility for converting Python 2 to Python 3 source code) for converting from PHP 5 to PHP 6. Nikic’s PhpParser would be useful for this, and he’s already made a tool to help spot things this RFC would break. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 final release
On Sat, Jun 14, 2014 at 2:45 PM, Johannes Schlüter johan...@schlueters.de wrote: Hi, On Fri, 2014-06-13 at 16:38 -0700, Stas Malyshev wrote: As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after the 5.5.0 release, which is on June 20th. Do we want to make one last release before EOL with latest security patches (probably in sync with 5.4/5.5 releases planned for June 29)? If so, I can scan the logs and backport the recent security-relevant patches. Last 5.3 was half a year ago so we probably have some, even with remote exploit potential. The last time this was discussed on security@ I intended for having one release in July to send 5.3 to eternal sleep I still plan to do that. I won't directly sync with 5.4/5.5, though (unless there is a critical issue requiring this) to have different news. I expect this final EOL to receive more media echo which shouldn't hide other releases. If there are specific changes you want to see in there please send a note to me (cc security@), I'll check myself, too. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi Johannes, I would like to cherry-pick http://git.php.net/?p=php-src.git;a=commit;h=4d804aa52d8c74ddcbdb07694b75b38c5eba8004 into PHP-5.3 so that REPORT_EXIT_STATUS=1 make test can be used on every php version provided by travis. currently one has to either manually execute run-tests.php or grepping the make test output for failures. Would that be ok with you? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
On Tue, Jul 8, 2014 at 4:51 PM, Andrea Faulds a...@ajf.me wrote: On 8 Jul 2014, at 15:48, Derick Rethans der...@php.net wrote: I've just voted no for this, because it introduces a tiny BC break. Now, I realize this is a tiny BC break, but it is just *those* that drive people nuts when upgrading. There is so much non-public code - a cursor check of Symfony and ZF is not representative. It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why not? It’s a tiny change which will bother some people but make everyone else’s life easier. Voted +1, obviously for having that in php6, not 5.7. This tiny BC is then more than OK. 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] Class var clean up coredump [5.3]
I found this late last week and haven't had time to open a bug, but after seeing the EOL thread on 5.3 (5.3.27) wanted to see if anybody knew what might be causing it: #0 0x005dffeb in gc_zval_possible_root (zv=0x7ff3cdc19010) at php-5.3.27/Zend/zend_gc.c:143 #1 0x005d10c2 in zend_hash_destroy (ht=0x7ff3cdc1bb60) at php-5.3.27/Zend/zend_hash.c:529 #2 0x005b902b in destroy_zend_class (pce=Variable pce is not available.) at php-5.3.27/Zend/zend_opcode.c:187 #3 0x005d12c2 in zend_hash_apply_deleter (ht=0x1cf4c30, p=0x250ac40) at php-5.3.27/Zend/zend_hash.c:612 #4 0x005d1688 in zend_hash_reverse_apply (ht=0x1cf4c30, apply_func=0x5b4790 clean_non_persistent_class) at php-5.3.27/Zend/zend_hash.c:762 #5 0x005b4ef1 in shutdown_executor () at php-5.3.27/Zend/zend_execute_API.c:310 #6 0x005c3405 in zend_deactivate () at php-5.3.27/Zend/zend.c:892 #7 0x0056e081 in php_request_shutdown (dummy=Variable dummy is not available.) at php-5.3.27/main/main.c:1703 #8 0x0064dac0 in main (argc=2, argv=0x7fff9c2b5538) at php-5.3.27/sapi/cli/php_cli.c:1382 test script here: http://www.brianfrance.com/software/php/class-crash.txt This seems to be fixed in 5.4 (5.4.24 at least), but wasn't sure if anybody remembered which commit fixed it and if it can be back ported to 5.3 before the final release. My guess is the temp var is getting set into the classes default property list and then cleaned up, so when the class is cleaned it it goes boom. May be a ref count issue. I will be looking into it later today or tomorrow, but figured I would ask. Thanks, Brian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: why do we not set http 500 for errors when the display_error is enabled
On Wed, Jun 25, 2014 at 5:25 PM, Johannes Schlüter johan...@schlueters.de wrote: On Wed, 2014-06-25 at 16:32 +0200, Ferenc Kovacs wrote: We can't set 500 response code if HTTP headers were already sent. we have the !SG(headers_sent) check for that, and I'm not proposing to remove that(albeit I think that we could handle the special scenario, when the only output is generated by the error, but that is a separate topic). I believe this causes some inconsistency, sometimes status code is changed, sometimes not. Uncertain which is worse - wrong code or harder to predict behavior. you mean it would be inconsistent if we would signal the error with a http 500 when it is technically possible (we haven't sent out the headers) versus when the error happened after the headers were already sent? if we consider this as inconsistency, we are already inconsistent, and I'm not sure what would be the consistent alternative: not sending http 500 at all? but as I mentioned I'm not really interested changing the headers already sent scenario (as there isn't much we could do), but I do think that the current behavior about only setting the response code to 500 if display_errors is disabled is questionable. I would like to know if you think that changing this is out of the question or not, and if we would change it, should it happen a minor or a major version. I also think it would make sense to document the current behavior, I couldn't find anything regarding this in the docs. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
On Tue, Jul 8, 2014 at 9:48 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Jul 8, 2014 at 4:51 PM, Andrea Faulds a...@ajf.me wrote: On 8 Jul 2014, at 15:48, Derick Rethans der...@php.net wrote: I've just voted no for this, because it introduces a tiny BC break. Now, I realize this is a tiny BC break, but it is just *those* that drive people nuts when upgrading. There is so much non-public code - a cursor check of Symfony and ZF is not representative. It is a tiny BC break and it’s for PHP NEXT (i.e 6 or 7), not 5.6. Why not? It’s a tiny change which will bother some people but make everyone else’s life easier. Voted +1, obviously for having that in php6, not 5.7. This tiny BC is then more than OK. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Also +1. Major version increments always have BC breaks, and not just tiny ones, either. --Kris
