Re: [PHP-DEV] Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli jpa...@php.net wrote: On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs tyr...@gmail.com wrote: sorry for the late reply. you are right and after looking into the implementation I think classes having custom object storage (eg. create_object) shouldn't assume that their __construct will be called, but either do the initialization in the create_object hook or validate in the other methods that the object was properly initialized. given that this lack of initialization problem is already present(you can extend such a class and have a __construct() in the subclass which doesn't call the parent constructor), and we want to keep the unserialize trick fixed (as that exposes this problems to the remote attacker when some code accepts arbitrary serialized data from the client) I see no reason to keep the limitation in the ReflectionClass::newInstanceWithoutConstructor() and allowing the instantiation of internal classes will provide a clean upgrade path to doctrine and co. ofc. we have to fix the internal classes misusing the constructor for proper initialization one by one, but that can happen after the initial 5.6.0 release (ofc it would be wonderful if people could lend me a hand for fixing as much as we can before the release), but we have to fix those anyways. This sounds reasonable to me. newInstanceWithoutConstructor does not have the same remote exploitation concerns as serialize, so allowing crashes here that can also be caused by other means seems okay to me (especially if we're planning to fix them lateron). Only additional restriction I'd add is to disallow calling it on an internal + final class. For those the __construct argument does not apply. For them the entity-extending-internal-class usecase doesn't apply either, so that shouldn't be a problem. Nikita Thanks for the prompt reply! I was considering mentioning the final constructors, but as we previously didn't checked that and from a quick look it seems that we are mostly using it as an easy/cheap way to make sure that the object is initialized properly (which could also happen when a subclass calls parent::__construct() from it's constructor) which isn't exactly the best usecase for final. But I don't really mind having that check. I'm +1 also with the idea. Just take care to have a clone_handler defined as well, as the default clone handler doesn't call create_object. http://lxr.php.net/xref/PHP_5_5/Zend/zend_objects.c#218 Julien thanks, I will keep that in mind when we start moving the initialization from the constructors into the create_object functions. I've also went ahead and created a pull request for the proposed changes: https://github.com/php/php-src/pull/733 as you can see I've taken Nikita's advice and internal classes with final constructors are still not allowed to be instantiated. When should we start patching those ? I guess asap ? Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
On Wed, Jul 23, 2014 at 11:09 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli jpa...@php.net wrote: On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli jpa...@php.net wrote: On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs tyr...@gmail.com wrote: sorry for the late reply. you are right and after looking into the implementation I think classes having custom object storage (eg. create_object) shouldn't assume that their __construct will be called, but either do the initialization in the create_object hook or validate in the other methods that the object was properly initialized. given that this lack of initialization problem is already present(you can extend such a class and have a __construct() in the subclass which doesn't call the parent constructor), and we want to keep the unserialize trick fixed (as that exposes this problems to the remote attacker when some code accepts arbitrary serialized data from the client) I see no reason to keep the limitation in the ReflectionClass::newInstanceWithoutConstructor() and allowing the instantiation of internal classes will provide a clean upgrade path to doctrine and co. ofc. we have to fix the internal classes misusing the constructor for proper initialization one by one, but that can happen after the initial 5.6.0 release (ofc it would be wonderful if people could lend me a hand for fixing as much as we can before the release), but we have to fix those anyways. This sounds reasonable to me. newInstanceWithoutConstructor does not have the same remote exploitation concerns as serialize, so allowing crashes here that can also be caused by other means seems okay to me (especially if we're planning to fix them lateron). Only additional restriction I'd add is to disallow calling it on an internal + final class. For those the __construct argument does not apply. For them the entity-extending-internal-class usecase doesn't apply either, so that shouldn't be a problem. Nikita Thanks for the prompt reply! I was considering mentioning the final constructors, but as we previously didn't checked that and from a quick look it seems that we are mostly using it as an easy/cheap way to make sure that the object is initialized properly (which could also happen when a subclass calls parent::__construct() from it's constructor) which isn't exactly the best usecase for final. But I don't really mind having that check. I'm +1 also with the idea. Just take care to have a clone_handler defined as well, as the default clone handler doesn't call create_object. http://lxr.php.net/xref/PHP_5_5/Zend/zend_objects.c#218 Julien thanks, I will keep that in mind when we start moving the initialization from the constructors into the create_object functions. I've also went ahead and created a pull request for the proposed changes: https://github.com/php/php-src/pull/733 as you can see I've taken Nikita's advice and internal classes with final constructors are still not allowed to be instantiated. When should we start patching those ? I guess asap ? Julien Not sure, on one hand, I would be glad seeing these fixed, but on the other hand I'm a little bit worried about introducing destabilizing changes this close to the release, and these problems existed for years (triggerable either through instantiating via the unserialize O: trick or through a subclass) without any reports before https://bugs.php.net/bug.php?id=67072 Agree. We could start on a case by case basis, knowing we still got at least one RC to try that. Then anyway we're gonna fix them into next 5.6 revisions, so ... Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
On Wed, Jul 23, 2014 at 11:12 AM, Julien Pauli jpa...@php.net wrote: On Wed, Jul 23, 2014 at 11:09 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Jul 23, 2014 at 10:57 AM, Julien Pauli jpa...@php.net wrote: On Wed, Jul 23, 2014 at 7:58 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 6:20 PM, Julien Pauli jpa...@php.net wrote: On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs tyr...@gmail.com wrote: sorry for the late reply. you are right and after looking into the implementation I think classes having custom object storage (eg. create_object) shouldn't assume that their __construct will be called, but either do the initialization in the create_object hook or validate in the other methods that the object was properly initialized. given that this lack of initialization problem is already present(you can extend such a class and have a __construct() in the subclass which doesn't call the parent constructor), and we want to keep the unserialize trick fixed (as that exposes this problems to the remote attacker when some code accepts arbitrary serialized data from the client) I see no reason to keep the limitation in the ReflectionClass::newInstanceWithoutConstructor() and allowing the instantiation of internal classes will provide a clean upgrade path to doctrine and co. ofc. we have to fix the internal classes misusing the constructor for proper initialization one by one, but that can happen after the initial 5.6.0 release (ofc it would be wonderful if people could lend me a hand for fixing as much as we can before the release), but we have to fix those anyways. This sounds reasonable to me. newInstanceWithoutConstructor does not have the same remote exploitation concerns as serialize, so allowing crashes here that can also be caused by other means seems okay to me (especially if we're planning to fix them lateron). Only additional restriction I'd add is to disallow calling it on an internal + final class. For those the __construct argument does not apply. For them the entity-extending-internal-class usecase doesn't apply either, so that shouldn't be a problem. Nikita Thanks for the prompt reply! I was considering mentioning the final constructors, but as we previously didn't checked that and from a quick look it seems that we are mostly using it as an easy/cheap way to make sure that the object is initialized properly (which could also happen when a subclass calls parent::__construct() from it's constructor) which isn't exactly the best usecase for final. But I don't really mind having that check. I'm +1 also with the idea. Just take care to have a clone_handler defined as well, as the default clone handler doesn't call create_object. http://lxr.php.net/xref/PHP_5_5/Zend/zend_objects.c#218 Julien thanks, I will keep that in mind when we start moving the initialization from the constructors into the create_object functions. I've also went ahead and created a pull request for the proposed changes: https://github.com/php/php-src/pull/733 as you can see I've taken Nikita's advice and internal classes with final constructors are still not allowed to be instantiated. When should we start patching those ? I guess asap ? Julien Not sure, on one hand, I would be glad seeing these fixed, but on the other hand I'm a little bit worried about introducing destabilizing changes this close to the release, and these problems existed for years (triggerable either through instantiating via the unserialize O: trick or through a subclass) without any reports before https://bugs.php.net/bug.php?id=67072 Agree. We could start on a case by case basis, knowing we still got at least one RC to try that. Then anyway we're gonna fix them into next 5.6 revisions, so ... Julien.P I spent some time today reviewing our internal bundled extensions searching the ones that overwrite create_object *and* have a dangerous __construct constructing internal object data. What I found *not safe*, throwing unwanted warnings hitting an undesired behavior, or even segfaulting, and thus needing patch : - Dom - Mysqli - sqlite3 (sqlite3stmt class segfaults) What I found *safe*, with checkers that check object is properly initialized, so not needing patch, but throwing exceptions or warnings when used bad constructed : - Date - fileinfo - Intl - Pdo - Reflection - SimpleXML* (not faulting, but could need a better implementation of the checks and the thrown error messages) - SPL Any extension not present in one of the two above lists is safe. The method I used is rather
Re: [PHP-DEV] Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs tyr...@gmail.com wrote: sorry for the late reply. you are right and after looking into the implementation I think classes having custom object storage (eg. create_object) shouldn't assume that their __construct will be called, but either do the initialization in the create_object hook or validate in the other methods that the object was properly initialized. given that this lack of initialization problem is already present(you can extend such a class and have a __construct() in the subclass which doesn't call the parent constructor), and we want to keep the unserialize trick fixed (as that exposes this problems to the remote attacker when some code accepts arbitrary serialized data from the client) I see no reason to keep the limitation in the ReflectionClass::newInstanceWithoutConstructor() and allowing the instantiation of internal classes will provide a clean upgrade path to doctrine and co. ofc. we have to fix the internal classes misusing the constructor for proper initialization one by one, but that can happen after the initial 5.6.0 release (ofc it would be wonderful if people could lend me a hand for fixing as much as we can before the release), but we have to fix those anyways. This sounds reasonable to me. newInstanceWithoutConstructor does not have the same remote exploitation concerns as serialize, so allowing crashes here that can also be caused by other means seems okay to me (especially if we're planning to fix them lateron). Only additional restriction I'd add is to disallow calling it on an internal + final class. For those the __construct argument does not apply. For them the entity-extending-internal-class usecase doesn't apply either, so that shouldn't be a problem. Nikita Thanks for the prompt reply! I was considering mentioning the final constructors, but as we previously didn't checked that and from a quick look it seems that we are mostly using it as an easy/cheap way to make sure that the object is initialized properly (which could also happen when a subclass calls parent::__construct() from it's constructor) which isn't exactly the best usecase for final. But I don't really mind having that check. I'm +1 also with the idea. Just take care to have a clone_handler defined as well, as the default clone handler doesn't call create_object. http://lxr.php.net/xref/PHP_5_5/Zend/zend_objects.c#218 Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye pierre@gmail.com wrote: hi Zeev, On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski z...@zend.com wrote: All, As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Dmitry and I wrote an RFC proposing that we merge phpng into master and turn it into the basis of the next major version of PHP (name TBD). The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! Quoting Dmitry's mail from last week phpng is an experimental branch, as such, I see no appealing reasons to replace master with phpng and use phpng as base for the next major version. I am not really surprised by this request, despite contradictory comments about this exact point in the past few weeks. Despite the excellent performance improvements, it is by far not ready to be used as base for the next major release, the release we will have to maintain for the next decade. There is almost no documentation, the APIs are not clean or inconsistent (just came back home, will provide details later) but having two separate zpp, same area's functions mixing use of zend_char and char (creating hard to catch bugs, not always catch-able at compile time f.e.), no (known) plan about when the experiments will stop and when or how deep the cleanup will be done. In other words, I cannot agree to replace master with phpng, not with its current state and it is definitively not what I could imagine as a base for php-next. A roadmap, undocumented and plan-less development (sorry, but stacking up a couple of % performance improvement has little to nothing to do with designing php-next) is the best way to fail to have what many of our users and developers could expect for php-next. Cheers, -- Pierre Hi I can only agree here. I'd like a clean API. We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last Old features and unused things should be cleaned up. Quickly caught, impacting the engine : - Resources are a hell, mixed with zend_lists etc... inconsitstent and absolutely PITA to develop with. - Streams need to be cleaned up and reworked to support full asynchronous IOs, which could involve threads, thus engine tied - Signals have been worked on starting with 5.4 (AFAIR), but never activated by default. I guess the actual implementation lacks a bit more reflection to be stable, and to finally propose signal managers into userland. ext/pcntl should be somehow merged to core, and this as well would involve engine work - TSRM need to find love, or to find a better replacement, which would involve a big engine work as well - ... and so on Macro hell should be reworked as inlined functions, and I'd like we start supporting C99 as well. Performance is a userland point. API, doc, and clean things are developers points, and IMO, they are as important. What about merging OPCache to the branch ? This was talked about at PHP5.5 release, has never happened yet, and doesn't seem planed. This could have a big impact on the engine codebase. I just cant believe we won't rework our API , fully and deeply, for PHP-Next. Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov dmi...@zend.com wrote: Hi Julien, Hi I can only agree here. I'd like a clean API. We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last I'm more than agree about internal cleanup. phpng benchmark results proved that we take the right direction and now we implemented most the ideas we had. Note that we tried not to change PHP behaviour in any way. Now it's a good time to start the cleanup work. Not changing behavior is nice and very hard work to do, so congrats on that one. If cleaning the API receives no-go because the cleanups would involve swaping some parameters in functions, or turning macros to inline functions , which drops some little percentage in performance on some rare compilers, then there will be a problem to me. We need a trade-off here. We can't leave unreadable code in, should this code be written in a specific way for performances. We can afford a little 1% or 2 IMO. Old features and unused things should be cleaned up. Quickly caught, impacting the engine : - Resources are a hell, mixed with zend_lists etc... inconsitstent and absolutely PITA to develop with. - Streams need to be cleaned up and reworked to support full asynchronous IOs, which could involve threads, thus engine tied - Signals have been worked on starting with 5.4 (AFAIR), but never activated by default. I guess the actual implementation lacks a bit more reflection to be stable, and to finally propose signal managers into userland. ext/pcntl should be somehow merged to core, and this as well would involve engine work - TSRM need to find love, or to find a better replacement, which would involve a big engine work as well - ... and so on Some of the topics above are really big... :) Macro hell should be reworked as inlined functions, and I'd like we start supporting C99 as well. Performance is a userland point. API, doc, and clean things are developers points, and IMO, they are as important. What about merging OPCache to the branch ? This was talked about at PHP5.5 release, has never happened yet, and doesn't seem planed. This could have a big impact on the engine codebase. What do you mean? isn't it already there. I'm also going to remove opcache code for old PHP versions in php-next. I was talking about merging the code bases. For example, shared memory model from OPCache could be merged into Zend/ and expose an API one could reuse in extensions needing SHM. Also, accelerator's code could be merged into Zend/zend_execute and Zend/ZendVM Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5.15RC1 is available for testing
Hi! Our RC1 of PHP 5.5.15 was just released today. You can fetch it from http://downloads.php.net/jpauli/ The Windows binaries are available at http://windows.php.net/qa/ This release contains a number of bugfixes. For the list of bugfixes that you can target in your testing, please refer to the NEWS file: https://github.com/php/php-src/blob/php-5.5.15RC1/NEWS Please test it carefully, and report any bugs in the bug system. The stable release is planned for July 24th, if no critical issues will be discovered in the RC. Thank you for your support. Julien Pauli Savid Soria Parra
Re: [PHP-DEV] Implemented fallocate() syscall in streams
On Tue, Jul 8, 2014 at 2:31 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: 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 :-). I admit that it would be nice for consistency, however I wonder how users will interpret the difference between ftruncate and fallocate. Julien -- 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. Regards Anatol Hey Anatol ;-) Would you mind working with me finalizing this patch so that we could merge it in master for a 5.7 and Next eventually ? I'll update the PR next week with tests, then we'll be able to talk about the implementation to use for crossplatform. Thank you Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Uniform Variable Syntax
On Wed, Jul 9, 2014 at 1:06 AM, Kris Craig kris.cr...@gmail.com wrote: 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. +1 as well. For a next major, every tip making things cleaner is welcome, and this is little BC. Julien -- 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] RFC: Expectations
On Mon, Oct 21, 2013 at 3:52 AM, Joe Watkins krak...@php.net wrote: On 10/20/2013 12:15 AM, Ferenc Kovacs wrote: On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll rst...@tutteli.ch wrote: Heya, I do not know how much it concerns this RFC but I came across the following page about an extension named Expect when I was searching for RFC Expect with google. http://php.net/manual/en/book.**expect.phphttp://php.net/manual/en/book.expect.php I suppose there would be a name clash between the extension and the new expect keyword. I do not know how internals usually deal with such problems, especially if it is within an extension, but I am sure someone will know it. Cheers, Robert it was discussed on irc, there is not problem here, because the ext name and the function name can't clash, and the ext doesn't have a function with the name of expect, so everything is fine afaik. Rasmus has pointed out that there is an expect:// stream wrapper. So looks like we need a new name ?? Ideas ?? Why ? The stream wrapper is always used in a string, so there is no parsing problem about the expect keyword. Am I missing something ? Julien.Pauli
[PHP-DEV] PHP 5.5.4 has been released
Hi! The PHP development team announces the immediate availability of PHP 5.5.4. This release fixes several bugs against PHP 5.5.3. All PHP users are encouraged to upgrade to this new version. For source downloads of PHP 5.5.4 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on: http://windows.php.net/download/ The list of changes is recorded in the ChangeLog at: http://www.php.net/ChangeLog-5.php#5.5.4 We would like to thank the contributors and the PHP community for making this release available. Regards, Julien Pauli David Soria Parra
Re: [PHP-DEV] Signature compatibility: Number of arguments
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
This is a spinoff from the variadics thread. Quoting Stas:
I also think this:
public function query($query, ...$params)
public function query(...$params)
should be legal too.
This is a general issue in PHP that we might want to fix: Currently a
method A is not compatible with a method B if A has less arguments than B.
E.g. both of the following are incompatible signatures:
public function foo($bar)
public function foo()
public function foo($bar = NULL)
public function foo()
I dont really agree.
One could use reflection on the parameter, thus expecting it to be here on
a child instance :
class Foo
{
public function bar($arg = null) { }
}
class Foo2 extends Foo
{
public function bar() { }
}
$o = new Foo; /* Switching to Foo2 will lead to an Exception */
$r = new ReflectionParameter(array($o, 'bar'), 'arg');
echo $r-getName();
PS : I remember having a long discussion with Gustavo, some time ago, about
LSP in PHP ; and we could not agree on some points, particularly concerning
optional parameters.
Julien.Pauli
Re: [PHP-DEV] PHP CLI setting cooked terminal mode
On Wed, Sep 18, 2013 at 4:20 PM, Alain Williams a...@phcomp.co.uk wrote:
On Wed, Sep 18, 2013 at 04:13:39PM +0200, Remi Collet wrote:
Le 18/09/2013 16:04, Alain Williams a écrit :
What is needed is for this to NOT be called if the standard output is
not
connected to a tty.
From your previous message:
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon
echo ...}) = 0
Which is standard input, not standard output
Yes - a typeo, sorry.
I can get it to not do this by connecting stdin to /dev/null:
./myScript /dev/null | less
qed
Should I raise this as a bug ?
So, I don't think there is any bug there.
The redirection of stdin to /dev/null is NOT a solution. You don't need to
do
this with scripts written in other languages (eg shell, perl). It makes
using
the script for the end user more difficult and strangely different from
scripts
written in other languages.
One could use ltrace -l to trace library calls.
On my laptop (Debian) :
ltrace -l /usr/lib/x86_64-linux-gnu/libedit.so.2 php -a
using_history(1, 38, 0x25000f, 712, 0x1087900) = 0
Interactive shell
tilde_expand(0xd48ef1, 0x24a0ae8, 0, 17, 149464)=
0x24c61c0
read_history(0x24c61c0, 0x7f0a6eb9f986, 0x8e0f5f, 0x7f0a6eb9f986, 0)= 0
readline(php php
Julien.Pauli
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
On Mon, Sep 9, 2013 at 3:48 PM, Ferenc Kovacs tyr...@gmail.com wrote: Currently the downloads page on http://php.net/ only lists the supported versions(5.3, 5.4, 5.5) and I think that http://windows.php.net/should be synced with that, so the 5.2 links should be removed. http://museum.php.net/ already has those binaries, so it would be still available for those who are looking for that version, but without the possible confusion that the 5.2 version is still supported on windows. Pierre, what do you think? There is no link from windows.php.net web sites to 5.2. They only remain in the downloads section, if accessed directly. yes, we are talking about the downloads page, which page is linked from like every release annonuncement on the windows.php.net frontpage(we even have 5.2 release announcements if you scroll down a bit). I think we should remove the 5.2 section from the downloads page. I agree as it's been EOLed. Julien.Pauli
Re: [PHP-DEV] realpath_cache_size description in php.ini
On Wed, Sep 4, 2013 at 8:28 PM, Bostjan Skufca bost...@a2o.si wrote: Hi all, there is no description to be found about what the value of realpath_cache_size actually is. Is it a) max number of files/dirs in the cache or b) overall cache size? I checked php.ini samples distributed with PHP 5.5.3, and documentation here: http://php.net/realpath-cache-size Can please someone here provide an answer? Documentation and php.ini update would be nice too :) This is a little bit complicated. The size represent the total number of bytes in the overall paths stored + some garbage. So if realpath cache stores an entry of say /tmp/foo/bar.baz, then it will add 16 bytes to the realpath cache size. i.e, the longer the paths, the higher the cache size should be. The formula is located at http://lxr.php.net/xref/PHP_TRUNK/TSRM/tsrm_virtual_cwd.c#643 The realpath_cache_size() PHP function documentation says Returns how much memory realpath cache is using. , and this is actually true, though it could be more accurate on how this memory is calculated. The realpath_cache_size INI description is Determines the size of the realpath cache to be used by PHP. This value should be increased on systems where PHP opens many files, to reflect the quantity of the file operations performed. It's not very specific either, I admit. Julien.Pauli
Re: [PHP-DEV] realpath_cache_size description in php.ini
On Thu, Sep 5, 2013 at 12:29 PM, Chris Wright chr...@aquacool.ltd.ukwrote: On Thu, Sep 5, 2013 at 10:07 AM, Julien Pauli julienpa...@gmail.com wrote: On Wed, Sep 4, 2013 at 8:28 PM, Bostjan Skufca bost...@a2o.si wrote: Hi all, there is no description to be found about what the value of realpath_cache_size actually is. Is it a) max number of files/dirs in the cache or b) overall cache size? I checked php.ini samples distributed with PHP 5.5.3, and documentation here: http://php.net/realpath-cache-size Can please someone here provide an answer? Documentation and php.ini update would be nice too :) This is a little bit complicated. The size represent the total number of bytes in the overall paths stored + some garbage. So if realpath cache stores an entry of say /tmp/foo/bar.baz, then it will add 16 bytes to the realpath cache size. i.e, the longer the paths, the higher the cache size should be. The formula is located at http://lxr.php.net/xref/PHP_TRUNK/TSRM/tsrm_virtual_cwd.c#643 The realpath_cache_size() PHP function documentation says Returns how much memory realpath cache is using. , and this is actually true, though it could be more accurate on how this memory is calculated. The realpath_cache_size INI description is Determines the size of the realpath cache to be used by PHP. This value should be increased on systems where PHP opens many files, to reflect the quantity of the file operations performed. It's not very specific either, I admit. Julien.Pauli I've updated the docs for the config option to reflect Julien's explanation, and added a link to the config option docs from the function docs Thx Chris, I didn't know if it were worth doing it, but you added the info, so it is cool. Thank you. Julien.Pauli
[PHP-DEV] PHP 5.5.4 RC1 tagged
Hi Internals, Our RC1 of PHP 5.5.4 has been released for testing. It fixes some bugs in the 5.5 branch. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. 5.5.4 GA is planned for September 19th. Thank you. Regards Julien and David
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 9:35 AM, Sebastian Bergmann sebast...@php.netwrote: Am 30.08.2013 03:23, schrieb Anthony Ferrara: All feedback is welcome. Can we please get rid off the __autoload() function first before we consider adding new functionality? Huge +1 to start deprecating this feature, then completely remove it. And to continue the discussion, I recall that we, as PHP contributors, disagreed to include a PSR-0 compatible autoloader into Core. So the argument of PSR-0 is not valid for me, as it has nothing to do with PHP internals and actually is just a recommandation we didn't want to merge into PHP. Perhaps is it also time to talk about this subject back and finally all agree on a default recommanded implentation of autoloading in PHP (internally supported) ? Julien.Pauli
Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
On Fri, Aug 30, 2013 at 3:23 AM, Anthony Ferrara ircmax...@gmail.comwrote: All, I have created a new draft RFC implementing function and constant autoloading in master: https://wiki.php.net/rfc/function_autoloading All feedback is welcome. Just to say : one benefit of this work would be to finally have autoload functionnality (which is a Core feature IMO) included in Zend/ and no more in an extension. Julien.Pauli
Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]
On Fri, Aug 30, 2013 at 10:56 AM, Jordi Boggiano j.boggi...@seld.be wrote: On 29.08.2013 09:52, Zeev Suraski wrote: I have to say that I'm not wildly enthusiastic about making this change over what appears to be a fairly minor comment in the license, and without even going into the discussion as to why we want to promote Evil :) The main concerns I have are: * Downwards compatibility. We've found one potential issue, how can we guarantee that there aren't others when we deal with a completely different implementation? I think that users that bump into apps suddenly breaking in obscure edge cases will not be very understanding when we explain to them that we did that over a licensing quirk - that I'm willing to bet they'll say isn't applicable to them... * Performance. Again, for the same reasons, I think it'll be difficult for us to defend this decision in this context as well. We switched to a 2x slower implementation over this? Really? I think that a better alternative would be enabling ext/jsonc to take over the ext/json symbol space so that people who care about the license issue, and/or are interested in the extra features - will be able to take advantage of it as a drop-in replacement. Debian can come with this switch turned on. I think it'd be best to resolve this in PHP because otherwise it means Debian ( Fedora?) users will have the bad surprise of a quirky implementation when deploying to prod, and I can imagine the impossible-to-reproduce issues that will follow. I would say, to stay in the pipe, that then it would be a Debian issue, not a PHP one. That said, your last proposal of at least having a switch in php like --enable-evil-json sounds better than the current state. If we do have an equivalent implementation though we might as well throw away the existing one instead of keeping two IMO, but that's a detail. Seems good. Julien.Pauli
Re: [PHP-DEV] Re: Always set return_value_ptr?
On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison ellison.te...@gmail.comwrote: On 27/08/13 10:40, Nikita Popov wrote: On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Is there any particular reason why we only pass return_value_ptr to internal functions if they have the ACC_RETURN_REFERENCE flag set? Why can't we always provide the retval ptr, even for functions that don't return by reference? This would allow returning zvals without having to copy them first (what RETVAL_ZVAL does). Motivation for this is the following SO question: http://stackoverflow.com/q/**17844379/385378http://stackoverflow.com/q/17844379/385378 Patch for this change can be found here: https://github.com/php/php-**src/pull/420https://github.com/php/php-src/pull/420 The patch also adds new macros to allow easy use of this feature called RETVAL_ZVAL_FAST/RETURN_ZVAL_**FAST (anyone got a better name?) If no one objects I'll merge this sometime soon. +1 Though looking through the ext uses, most functions returning an array build it directly in return_value and thus avoid the copy. I also see that you've picked up all of the cases in ext/standard/array.c where these macros can be applied. There's another one in string.c, in PHP_FUNCTION(pathinfo), that could be applied as well, though there's little performance gain in avoiding the copy of a 4 element string array. BTW, looking at this pathinfo code, it doesn't do what the documentation says it does -- or at least this states that the optional argument if present should be _one_ of PATHINFO_DIRNAME, PATHINFO_BASENAME, PATHINFO_EXTENSION or PATHINFO_FILENAME. However, if a bitmask is supplied then this function returns the element corresponding to the lowest bit value rather than an error return, for example: $ php -r 'echo pathinfo(/tmp/x.fred, PATHINFO_FILENAME|PATHINFO_** EXTENSION),\n;' fred This is a bizarre behaviour. At a minimum the documentation should actually state what the function does. Or do we bother to raise a patch to fix this sort of thing, given that returning an empty string (or more consistently with other functions, NULL) in this case could create a BC break with existing buggy code? This is weird, yes. It's not the lowest bit value that is returned, but the first element put in the array (as zend_hash_get_current_data() is used with no HashPosition) , which is even more confusing. How to explain that in the documentation ? :| Julien.Pauli
Re: [PHP-DEV] Refactored magic methods
On Thu, Aug 29, 2013 at 5:59 PM, Levi Morrison morrison.l...@gmail.comwrote: On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov nikita@gmail.comwrote: On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli jpa...@php.net wrote: Hi internals. I started a work of refactoring magic methods from internals. The first goal was to never write ourselves things like __get, but use macros for those names. (get, set, invoke, etc...). A second goal was to rewrite some parts of the compiler which looked like code duplication which could benefit from macro refactoring. I did that. All tests pass. It may look uglier for people who dont like having more macros, but anyway, we can cherry pick some commits, etc... If you have ideas or things to say, I'm listening. https://github.com/jpauli/php-src/compare/macroing I'm not really a fan of heavy macro usage, so here an alternative suggestion: https://github.com/nikic/php-src/commit/375bd7911fd117696b8b5d63c104fd588d69c409 Basically, instead of going through all the magic methods manually we define a structure holding information on magic methods and then loop through it doing generic checks. The above example only changes zend_check_magic_method_implementation, but the idea can be generalized to the other occurances of magic method checks (making the structure a global constant so they can all make use of the information in there.) Nikita I think I like Nikita's version better. Fewer macros are nicer in my opinion. I like yes, I think we can mix both by having a global containing all magic method infos, and some macros to use them. I'll propose another patch based on that ;-) Thank you, Julien.Pauli
Re: [PHP-DEV] Pull requests report (27/8/2013)
On Tue, Aug 27, 2013 at 8:00 PM, Lior Kaplan lio...@zend.com wrote: Hi, I'm please to say that we keep processing the requests faster and faster, leaving only few not handled in their first week. Thanks for everyone who helped. New: #420 https://github.com/php/php-src/pull/420 Always provide retval ptr #421 https://github.com/php/php-src/pull/421 Dedicated syntax for variadic parameters Merged requests: #197 https://github.com/php/php-src/pull/197 fputcsv improvements to allow RFC 4180 compliance #237 https://github.com/php/php-src/pull/237 Fix DateTime, when use it with D/l in format and textual day have dot at the end #322 https://github.com/php/php-src/pull/322 Fix DateInterval-days value #414 https://github.com/php/php-src/pull/414 Fix #65483: quoted-printable encode stream filter incorrectly encoding #415 https://github.com/php/php-src/pull/415 Remove duplicate calls to set filename lineno for the DTRACE_FUNCTION_ENTRY/RETURN cases #417 https://github.com/php/php-src/pull/417 Stricter libc-client symlink check #419 https://github.com/php/php-src/pull/419 Test extension xmlrpc encode type double and string decode type string and int Closed requests (without merge): #418 https://github.com/php/php-src/pull/418 Add test for #65499 (not a PHP bug) Still open (21 days): #406 https://github.com/php/php-src/pull/406 OnEnable INI MH for opcache causing strangeness #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity Kaplan On Thu, Aug 22, 2013 at 2:24 AM, Lior Kaplan lio...@zend.com wrote: (reporting about two weeks) Merged requests (past 7 days): #359 https://github.com/php/php-src/issues/359 PHPTests for the DOMDocument::load and DOMDocument::loadXML #360 https://github.com/php/php-src/pull/360 Bug44168 #381 https://github.com/php/php-src/issues/381 Fixed #65225: PHP_BINARY incorrectly set #395 https://github.com/php/php-src/issues/395 typofixes - code related #402 https://github.com/php/php-src/issues/402 make the bison version check a blacklist #403 https://github.com/php/php-src/issues/403 Fix #61345: fix install of CGI binary #404 https://github.com/php/php-src/issues/404 php.ini-development/production: remove php_zip.dll #405 https://github.com/php/php-src/issues/405 Fixbug: phpize --clean will delete include/*.h #410 https://github.com/php/php-src/pull/410 Fix for php bug #64802 #411 https://github.com/php/php-src/issues/411 Use pkg-config to detect iodbc #412 https://github.com/php/php-src/issues/412 Create test to the extension xmlrpc, encode array and int. Closed requests (without merge): #325 https://github.com/php/php-src/issues/325 Add schema default/fixed value support in DOM (merged in April, closed now). #329 https://github.com/php/php-src/issues/329 Allow major versions of bison (done as part of #402). New: #406 https://github.com/php/php-src/pull/406 OnEnable INI MH for opcache causing strangeness #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #414 https://github.com/php/php-src/pull/414 Fix #65483: quoted-printable encode stream filter incorrectly encoding #415 https://github.com/php/php-src/pull/415 Remove duplicate calls to set filename lineno for the DTRACE_FUNCTION_ENTRY/RETURN cases #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity Kaplan Thank you very much for helping with this stuff. Julien Pauli
Re: [PHP-DEV] Re: Always set return_value_ptr?
On Tue, Aug 27, 2013 at 11:40 AM, Nikita Popov nikita@gmail.com wrote: On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Is there any particular reason why we only pass return_value_ptr to internal functions if they have the ACC_RETURN_REFERENCE flag set? Why can't we always provide the retval ptr, even for functions that don't return by reference? This would allow returning zvals without having to copy them first (what RETVAL_ZVAL does). Motivation for this is the following SO question: http://stackoverflow.com/q/17844379/385378 Patch for this change can be found here: https://github.com/php/php-src/pull/420 The patch also adds new macros to allow easy use of this feature called RETVAL_ZVAL_FAST/RETURN_ZVAL_FAST (anyone got a better name?) If no one objects I'll merge this sometime soon. After discussing this point, I'm +1 with this patch. Julien.Pauli
Re: [PHP-DEV] [RFC] Constant Scalar Expressions
On Tue, Aug 13, 2013 at 6:12 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Hello all,
I'd like to propose a new RFC for 5.NEXT:
https://wiki.php.net/rfc/const_scalar_expressions
This allows for defining constant expressions which are resolved at compile
time.
for example:
const FOO = 1 + 1;
static $bar = 1 2;
function foo($a = 1 | 2) {}
class foo {
public $bar = 1 2;
}
Thoughts?
Haha Anthony, so strange you think about this point I was just myself
figuring out yesterday.
I'am obviously +1.
Julien Pauli.
Re: [PHP-DEV] [RFC] Constant Scalar Expressions
On Wed, Aug 14, 2013 at 12:44 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Stas,
On Wed, Aug 14, 2013 at 5:01 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
https://wiki.php.net/rfc/const_scalar_expressions
I like the idea, but absence of constant support makes this thing much
less useful, as you can't do things like:
public $angle = M_PI/2;
I think this is one of the reasons this idea was never implemented -
because without constant support you're limited to doing things that are
quite obvious and trivial.
Yeah, having constants in those expressions would be great. If only
constants in PHP were actually constant...
But this win is really cheap (a trivial change to the parser), so I
figured it was worth proposing separately. If we want to add the opcode
stream later to do expressions for constant values, we can. This just gives
us the quick win today of allowing relatively trivial, but important
expressions.
The biggest wins I see are in power-of-2 math:
I agree !
class Foo {
const FLAG_1 = 1 0;
const FLAG_2 = 1 1;
const FLAG_3 = 1 2;
const FLAG_4 = 1 3;
const FLAG_5 = 1 4;
const FLAG_6 = 1 5;
const FLAG_7 = 1 6;
}
Julien
Re: [PHP-DEV] Refactored magic methods
On Fri, Aug 2, 2013 at 9:55 PM, Levi Morrison morrison.l...@gmail.comwrote: If you have ideas or things to say, I'm listening. https://github.com/jpauli/php-src/compare/macroing Is there a reason you switched from names like `__toString` to `__tostring` (https://github.com/jpauli/php-src/compare/macroing#L2R12)? Yes because I use the same word for structure members access and for error message. That makes the refactoring takes place actually, if I had to change just one letter to capitalize it for just one method, that would add lots of code just for treating that particular case :-p Visually the macros clean things up a lot and better convey the intent behind the if / else if chain. However, I don't really like having a macro that works off of an `ELSE`, it just feels wrong. I don't have a better suggestion though. Yes elses inside macros are not a good idea, I pushed a different implementation having elses out of macro definitions. Julien.Pauli
[PHP-DEV] PHP 5.5.2 RC1 is tagged
Hi Internals, Our RC1 of PHP 5.5.2 has been released for testing. It fixes some bugs in the 5.5 branch. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. 5.5.2 GA is planned for August 15th. Thank you. Regards Julien and David
[PHP-DEV] Refactored magic methods
Hi internals. I started a work of refactoring magic methods from internals. The first goal was to never write ourselves things like __get, but use macros for those names. (get, set, invoke, etc...). A second goal was to rewrite some parts of the compiler which looked like code duplication which could benefit from macro refactoring. I did that. All tests pass. It may look uglier for people who dont like having more macros, but anyway, we can cherry pick some commits, etc... If you have ideas or things to say, I'm listening. https://github.com/jpauli/php-src/compare/macroing Julien.Pauli
Re: [PHP-DEV] The day has come
On Wed, Jul 31, 2013 at 11:13 PM, Michael Wallner m...@php.net wrote: Hi all! Tomorrow, August 1st 2013, is the day, it is *my* day. Some of you might already know [1] that I've been hired as a full-time PHP core developer by SmugMug. I'll officially start tomorrow. I hope that I can do a great job for all of us who need and love to use PHP. I hope that you will bear with me while I get used to all that stuff again I missed all the years busy with other things. I hope that I can contribute to existing, prospective and yet unknown projects within the PHP community in a meaningful and constructive way. Talk to me if something about me or PHP bugs you. Talk to me if you need help with your endeavour making PHP better. Talk to me even if you can't stand my attitude. Thank you and apologize my huge excitement! Congrats, looking forward in working together with you :-) Perhaps conferences are also planned for you ? If so, then I'm looking fwd in seeing you in real then ;-) Julien.Pauli
[PHP-DEV] Adding \Closure::isBindable()
Hi all. From a recent discussion, we noticed that there is no easy user-level way to know if a given closure is bindable or not. Sure, the debatte about https://bugs.php.net/bug.php?id=64761 is still open, I dont see why a static closure is not bindable, knowing that a global scope defined closure is, and it can contain $this. I'm feeling like there is a non sense in this design, but anyway. To prevent such code : https://github.com/atoum/atoum/blob/master/classes/test/adapter/invoker.php#L191 , I added \closure::isbindable(). It's at https://github.com/jpauli/php-src/compare/static-closures , if you have thoughts ? Julien.Pauli
Re: [PHP-DEV] [PATCH] Constification of some PHP API calls
On Mon, Jul 29, 2013 at 12:01 PM, Andrey Hristov p...@hristov.com wrote: Hi, after experiencing again warnings about conversion from const char * to char * when calling some PHP API functions I decided to spend some time and constify a few of these. The result is a patch that constifies the Streams API, and few functions in Zend and TSRM (to which I have no karma). Most of the changes are conversion of char * to const char * parameters, where applicable. In a few places string lengths are changed from int to size_t. Few functions return now const char * instead of char * (the caller did not modify/release these before). The patch is against php-src because it changes API which can be only done in a new version. Opinions? I'm +1. About strings sizes from int to size_t , you perhaps could sync with Anthony who worked hard recently on such changes, especially regarding zval string type. Julien.Pauli
[PHP-DEV] PHP 5.5.1 released
Hi internals, We just released PHP 5.5.1. This release includes bug fixes as well as a security fix. For changes in PHP 5.5.1, please consult the PHP 5 ChangeLog. Release Announcement: http://www.php.net/release_5_5_1.phphttp://www.php.net/release_5_5_0.php Downloads:http://www.php.net/downloads.php#v5.5 Changelog: http://www.php.net/ChangeLog-5.php#5.5.http://www.php.net/ChangeLog-5.php#5.5.0 1 regards, Julien Pauli David Soria Parra
Re: [PHP-DEV] Passing specific bison to build
On Wed, Jul 17, 2013 at 4:00 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I've upgraded to Fedora 19 and bison is too new for PHP 5.4/5.3 I would like to users to select specific bison to build with. --- a/Zend/acinclude.m4 +++ b/Zend/acinclude.m4 @@ -12,7 +12,7 @@ AC_DEFUN([LIBZEND_BISON_CHECK],[ bison_version=none if test $YACC; then AC_CACHE_CHECK([for bison version], php_cv_bison_version, [ - bison_version_vars=`bison --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | + bison_version_vars=`$YACC --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | php_cv_bison_version=invalid if test -n $bison_version_vars; then set $bison_version_vars To build with specific bison, you may do YACC=/usr/local/bin/bison1 ./configure Any comments? +1. Would be very useful for RMing as well, as we have to test different bison versions and use one for RMing which may not be the system's one. Julien.Pauli
Re: [PHP-DEV] UNKNOW:0, what is it?
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/**fa8611c81ee72839cdff3e72b18cc5* *86feb4aa29https://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 ? 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
Re: [PHP-DEV] Request for comments - new PHP feature: return typing
On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT patrickalla...@php.netwrote:
2013/6/26 Maxwell m...@maxvandervelde.com:
Sherif,
I have to disagree with you on this in the same way that we have type
hints
for input variables on methods, this could also be useful.
Consider an interface with a getter method defined. As it stands now in
php, they're not entirely useful, since you can't define what type of
object your expecting from the implementer. That greatly reduces the
functionality of an interface and this proposal gives solution to that
problem.
Florin,
I think the overall concept is good, I want to see something like this in
the future, but I think this might be the wrong approach. I don't think
we
should be hinting primitives. if we're going to have a return type hint
on
a method, I would have it match the functionality of the input type hints
for functions we already have, where you can hint at an instance of an
object type, such as Iterator or StdClass, or an array, but not hint
primitives such as int and string, like I currently see in the draft.
Also, you should be aware that your proposed syntax for the return type (
type ) is interfering with:
https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
me.
Thanks Maxwell, you summarized very well what I was thinking about it.
So +1 from me for the general feature at a first glance, but it should
then be very close to what is possible with input type hinting.
It makes it possible to write interfaces that acts like specifications
and to easier the writing of:
class Foo {
public function bar($input) {
$return = Baz::foo($input);
if (!$return instanceof ReturnType)
trigger_error(Cannot divide by zero, E_USER_ERROR); //
or throwing some RuntimeException
return $return;
}
}
to:
class Foo {
public function ReturnType bar($input) {
return Baz::foo($input);
}
}
+1 for the global idea as this would help so much OO programs and framework
based programs.
But what Sherif said proves as well the limits of the idea. PHP is not
strongly typed. So each check, should it be type hinting or return type
hinting, has to be done at runtime , which is bad for performances.
Not talking about the type juggling which could lead the programmer as
shooting himself.
Julien.Pauli
[PHP-DEV] Re: OPCache documentation
On Wed, May 15, 2013 at 3:54 PM, Julien Pauli jpa...@php.net wrote: Hi all, As you know, 5.5 final is coming soon. We are in RC, so mainly stabilizing stuff and preparing the final release for anyone to setup 5.5 on their servers. I see the documentation migration guide has already been commited, that's a good new. I also see that new features we ship in 5.5 are online in the documentation, great ! But a crucial feature is missing doc : OPCache. As this feature is a very big step in PHP's life (we finally have a recommanded, bundled opcode cache system, and I'm very proud of this personnaly), I think it is crucial to have a good documentation about it. Has anyone started to write some doc about OPCache ? Another subject is APC. We have its doc on php.net, all right. What I would like is we patch APC doc when 5.5 final gets released, to clearly show our mind about it. That way, any people using 5.5 should be able to read in the doc that APC has support has been interrupted, that APC should never be used together with OPCache, and that OPCache is now the standard recommanded OPCode caching solution for 5.5, 5.4 and 5.3. It is crucial to communicate one this point for our users. Then will come the User cache debate Thank you. Up. Could we at least plan such a project ? 5.5 is released now. I know we are still having trouble about OpCache particulary under Windows. I dont shadow that. I would just like we start thinking about writing documentation for OPCache features and merge them to our official documentation. If it's already planned by someone, just let me know ;-) Thx. Julien.Pauli
[PHP-DEV] PHP 5.5.0 final has been released!
Hello! The PHP Development Team would like to announce the immediate release of PHP 5.5.0. This release includes a large number of new features and bug fixes. A separate release announcement is also available. For changes in PHP 5.5.0 since PHP 5.4, please consult the PHP 5 ChangeLog. Release Announcement: http://www.php.net/release_5_5_0.php Downloads:http://www.php.net/downloads.php#v5.5 Changelog:http://www.php.net/ChangeLog-5.php#5.5.0 Thanks to all contributors that made this new version available. regards, David Soria Parra Julien Pauli
Re: [PHP-DEV] Internal object orientation documentation available!
On Wed, Jun 12, 2013 at 10:04 PM, Nikita Popov nikita@gmail.com wrote: On Wed, Jun 12, 2013 at 11:04 AM, Terry Ellison ellison.te...@gmail.com wrote: On 10/06/13 19:33, Nikita Popov wrote: We just published some rather extensive documentation on internal object orientation: http://www.phpinternalsbook.**com/classes_objects.html http://www.phpinternalsbook.com/classes_objects.html This is part of a larger project aimed at documenting the engine and making it accessible to new contributors. This looks like an excellent beginning so thanks. A few general comments: 1) I notice that your book is © Copyright 2013, Julien Pauli - Anthony Ferrara - Nikita Popov. All Rights Reserved rather than GDFL or one of the CC variants of open document licences. They only issue that I see here is that I -- and possibly others -- might be a bit guarded in providing comment and input if that content was being transferred to the authors unconditionally. Also if you are reserving all rights then you will need to be careful to ensure that all the content is yours and not extracted from an open or other 3rd party source. Surely this going to add to your authoring burden? This is just a legal precaution, because we are not yet exactly sure about the publishing formats for this project. If we wanted to actually have a (printed) book, then questions of ownership can become problematic. Anyway, I'm pretty sure that we will publish this under a CC license eventually. 2) Wikipedia, for example, contains a lot of good in-depth explanation of CompSci concepts and standard patterns such as http://en.wikipedia.org/wiki/**Hash_table http://en.wikipedia.org/wiki/Hash_table. You might consider the content cut: when you include basic discussion of 101 principles (e.g. on HashTables); and when you limit your content to their PHP-specific implementation, with suitable references to the 101 stuff. Tending to the former will make the book a lot longer, albeit standalone. Your call, but I would have thought that the majority of the readership by nature will have some CompSci background and so want to skip the 101 stuff, or be referenced out to the appropriate in-depth WP or other reference. We don't have particularly much 101 stuff to cover (basically just hashtables), in which case I think its better to include a small introduction to the topic to make things self-contained. Also, this project is targeted not just at developers with years of C experience, but also at people coming from a more higher-level (PHP) background, in which case intimate knowledge of things like hashtables probably can't be expected. 3) What is your preferred markup format for feedback and contributions? E.g. do you maintain an ODF or Docbook XML under some accessible git repository, or is is a case of (for example) hashtables/basic_structure.html para at line 138. Not quite true that the arBucket array will never shrink down: you can not reduce a PHP array, you only can grow it. You can always implement your own resizer by realloing the arBucket array and the calling zend_hash_rehash() to do this. (This would be a good standard hash API function by the way. Heh, how did you get to that page? Wasn't supposed to be linked anywhere, as that chapter isn't done yet. In any case, we are writing this in RST (reStructured Text) in a private git repo (which will be made public sometime down the road). So if you have feedback, no need to write text in any particular format, just point us to what wrong / missing (or any other suggestions) and we'll fix it. Regarding your particular example: Agree that this wasn't right in that formulation. The text now says while the arBuckets array automatically grows, it will *not* shrink when you remove elements. I would rather not mention the hack to implement the shrinking though, because its bad style to directly mess with the members of the HT. Yes that was my writings. As I'm not English :-) I may miss words or sometimes turn sentences to a different meaning from what I initially thought in my native language. Nikita fixes that ;-) Julien.Pauli
Re: [PHP-DEV] Internal object orientation documentation available!
On Wed, Jun 12, 2013 at 7:05 AM, Michael Wallner m...@php.net wrote: On 10 June 2013 20:33, Nikita Popov nikita@gmail.com wrote: Hi internals! We just published some rather extensive documentation on internal object orientation: http://www.phpinternalsbook.com/classes_objects.html This is part of a larger project aimed at documenting the engine and making it accessible to new contributors. Any feedback is appreciated! That looks awesome; just asking: why didn't it go into http://php.net/internals? Well, we prefer writing in rst format than docbook. We could link from php.net/internals to this URL as well , or , we could convert rst to docbook, I heard about tools doing that. Anyway, as everybody can see, it is far from beeing finished , so many more things to say... Julien.Pauli -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal object orientation documentation available!
On Wed, Jun 12, 2013 at 1:04 PM, Derick Rethans der...@php.net wrote: On Wed, 12 Jun 2013, Julien Pauli wrote: Well, we prefer writing in rst format than docbook. We could link from php.net/internals to this URL as well , or , we could convert rst to docbook, I heard about tools doing that. http://zetacomponents.org/documentation/trunk/Document/tutorial.html#restructured-text has an example even! That's great ! This, together with tools such as Pandoc will surely do the job. Julien.Pauli
Re: [PHP-DEV] Internal object orientation documentation available!
On Wed, Jun 12, 2013 at 11:04 AM, Terry Ellison ellison.te...@gmail.comwrote: On 10/06/13 19:33, Nikita Popov wrote: We just published some rather extensive documentation on internal object orientation: http://www.phpinternalsbook.**com/classes_objects.htmlhttp://www.phpinternalsbook.com/classes_objects.html This is part of a larger project aimed at documenting the engine and making it accessible to new contributors. This looks like an excellent beginning so thanks. A few general comments: 1) I notice that your book is © Copyright 2013, Julien Pauli - Anthony Ferrara - Nikita Popov. All Rights Reserved rather than GDFL or one of the CC variants of open document licences. They only issue that I see here is that I -- and possibly others -- might be a bit guarded in providing comment and input if that content was being transferred to the authors unconditionally. Also if you are reserving all rights then you will need to be careful to ensure that all the content is yours and not extracted from an open or other 3rd party source. Surely this going to add to your authoring burden? We just put copyright here, but the final licence will definitely be permissive and CC based. PDFs and other final formats will be available too. 2) Wikipedia, for example, contains a lot of good in-depth explanation of CompSci concepts and standard patterns such as http://en.wikipedia.org/wiki/**Hash_tablehttp://en.wikipedia.org/wiki/Hash_table. You might consider the content cut: when you include basic discussion of 101 principles (e.g. on HashTables); and when you limit your content to their PHP-specific implementation, with suitable references to the 101 stuff. Tending to the former will make the book a lot longer, albeit standalone. Your call, but I would have thought that the majority of the readership by nature will have some CompSci background and so want to skip the 101 stuff, or be referenced out to the appropriate in-depth WP or other reference. 3) What is your preferred markup format for feedback and contributions? E.g. do you maintain an ODF or Docbook XML under some accessible git repository, or is is a case of (for example) Actually we would like to keep the lead on this project , as we are still writing, and as you could see there is so much work still to be done, we don't really think about feedbacks yet. If we were about getting some feedbacks, at this stage, this would add more work for us, and at this stage still : things may still move. We have even not published the full TOC yet , though we (3 authors) agreed with it. To let you know, we started this project on November 1st 2012. We'd like the book to be interesting for many people, whoever they are, so, we will add chapters about more general purpose on CompuSci, though they wont be as detailed as the true-PHP ones. Julien.Pauli
[PHP-DEV] PHP 5.5 RC3 is ready
Hi Internals, We juste tagged and release PHP 5.5.0 RC3. It fixes some bugs against RC2 code. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. We had bloking bugs so we had to release another RC. Expect another RC or a stable release to be announced for June 20th. Thank you. Regards Julien and David
Re: [PHP-DEV] 5.NEXT Integer and String type modifications
+1 , that will make a big diff . I'm here to help others to go forward. Julien.P On Tue, Jun 4, 2013 at 8:33 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Jun 4, 2013 at 6:59 AM, Michael Wallner m...@php.net wrote: +1 for the idea +1 for Z_STRSIZE at least Z_STRSIZET for the reason explained earlier :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP5.5 RC2 has been tagged
Hi Internals, Our RC2 of PHP 5.5.0 has been released for testing. It fixes some bugs and improves stability against RC1 code. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. This second RC could be the last one. Depending on bug reports, expect another RC or a stable release to be announced for June 6th. Thank you. Regards Julien and David
[PHP-DEV] OPCache documentation
Hi all, As you know, 5.5 final is coming soon. We are in RC, so mainly stabilizing stuff and preparing the final release for anyone to setup 5.5 on their servers. I see the documentation migration guide has already been commited, that's a good new. I also see that new features we ship in 5.5 are online in the documentation, great ! But a crucial feature is missing doc : OPCache. As this feature is a very big step in PHP's life (we finally have a recommanded, bundled opcode cache system, and I'm very proud of this personnaly), I think it is crucial to have a good documentation about it. Has anyone started to write some doc about OPCache ? Another subject is APC. We have its doc on php.net, all right. What I would like is we patch APC doc when 5.5 final gets released, to clearly show our mind about it. That way, any people using 5.5 should be able to read in the doc that APC has support has been interrupted, that APC should never be used together with OPCache, and that OPCache is now the standard recommanded OPCode caching solution for 5.5, 5.4 and 5.3. It is crucial to communicate one this point for our users. Then will come the User cache debate Thank you. Julien.Pauli
[PHP-DEV] First RC of PHP5.5 available
Hi Internals, Our RC1 of PHP 5.5.0 has been released for testing. It fixes some bugs and possible memleaks against last beta. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. We are now RC, this means stability only. Next RC is expected for May 23h. Thanks you all contributors. Regards Julien and David
Re: [PHP-DEV] Continued try blocks
On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard ama...@amaury.net wrote: 2013/4/27 Ferenc Kovacs tyr...@gmail.com please don't reuse the continue keyword for it. There are a bunch of code out there where which uses exceptions in a loop context. For example you have a retry counter decremented in a loop and you catch the exceptions and retry until the retry limit is reached. Fair enough. We can use resume. continue is just a keyword (syntactic sugar) we sure can change, I like resume yes :-) Julien.Pauli
[PHP-DEV] Continued try blocks
Hello internals,
I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand the idea :
*?php*
*
*
*try {*
* foo();*
* bar();*
* baz();*
*} catch (SomeException $e) {*
*dosomestuff();*
*continue; /* Here is the feature, go back to try block */*
*} catch (Exception $e) {*
*dosomething();*
*}*
The continue keyword would resume the execution from where it had
diverged, according to the function which led to the SomeException
catch block.
So, in this example, if, say, bar() throws a SomeException , the code
would then resume and execute baz() after the catch block.
Just presenting the idea here, no RFC actually , I'm collecting
thoughts and notices.
Julien.Pauli
[PHP-DEV] PHP 5.5 beta4 available
Hi Internals, PHP 5.5.0 Beta 4 has been released for testing. It fixes some bugs against beta 3. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. We now enter in RC stage, 1st RC is expected for May 9th. Thanks to all people that worked on the project to make PHP 5.5 a mature project. Regards Julien and David
Re: [PHP-DEV] Re: PHP 5.5 beta4 available
On Thu, Apr 25, 2013 at 1:26 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Julien Pauli in php.internals (Thu, 25 Apr 2013 10:45:17 +0200): PHP 5.5.0 Beta 4 has been released for testing. It fixes some bugs against beta 3. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa The windows packages aren't there yet. And I am getting all kinds of curl-stream errors when I try to build beta4 including php_curl.dll myself (VC11, x64, nts). Huh, sorry about that. David just uploaded back the right packages, you should find them on http://downloads.php.net/dsp now and be able to build them for Windows platform. Sorry. Julien.Pauli
Re: [PHP-DEV] Re: PHP 5.5 beta4 available
On Thu, Apr 25, 2013 at 2:36 PM, Pierre Joye pierre@gmail.com wrote: hi, On Thu, Apr 25, 2013 at 1:26 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Julien Pauli in php.internals (Thu, 25 Apr 2013 10:45:17 +0200): PHP 5.5.0 Beta 4 has been released for testing. It fixes some bugs against beta 3. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa The windows packages aren't there yet. And I am getting all kinds of curl-stream errors when I try to build beta4 including php_curl.dll myself (VC11, x64, nts). The build was broken due to the curl stream removal commit. The announce should not have been sent before the builds have been validated again but... :) Yes Pierre, I apologize for this. I'm still learning RM ;-) Won't reiterate. Julien.Pauli
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Tue, Apr 16, 2013 at 3:01 PM, Pierrick Charron pierr...@adoy.net wrote: I created a straightforward RFC that you can access here https://wiki.php.net/rfc/curl-wrappers-removal-rfc . If someone have something more to add in it, feel free. Otherwise I will start the vote so that we could remove it in 5.5 ASAP. Thx Pierrick, it's ok for me :) Julien.Pauli
[PHP-DEV] WIP on extension loading improvement
Hello, I recently worked on the extension loading system to fully understand it and try to improve it while keeping full BC. Joe helped me in this task. I wrote an RFC giving details about what we have today ( https://wiki.php.net/internals/extensions ) The branch can be found here : https://github.com/jpauli/php-src/tree/extensions_improvements As I plan to merge it against master and probably 5.5 (not sure, depend on time), I will write an RFC about it to show people what were the ideas for this branch. I also plan to rewrite much more things, but that will be against master, and that will also be RFC'ed I'm actually running a problem. Nowadays, our test suite doesn't test anything about extensions, so I planned to write tests as well. The goal is to test how the engine loads extensions, should they be Zend Engine exts or PHP exts, with all the possible scenarios. For that, I need the test suite to be able to load several pre-compiled extensions that will each be used to test one test case. The idea is to modify the build script so that it compiles all those little zend_test_extensions only when Debug mode is activated (as those exts are just meant for testing purpose) So, I merged a zendtest extension that can be built as Zend Engine ext or PHP ext or even both, to test the patches I added to the branch. But, I cant make the build system compile an extension having a dynamic name. I'm very noob to AutoTools and m4, and it's quiet complicated to debug such tools. Actually, I tried a concatenation like PHP_NEW_EXTENSION(zend_test_extension_[$PHP_ZEND_TEST_EXTENSION_BUILD_ENGINE], zend_test_extension.c, $ext_shared) But this does not work, autom4te gives errors or generates a wrong-syntaxed configure. So if you have ideas about that, I'm listening :-) If someone has autotools experience, please, share it on IRC on here :-) Thx Julien.Pauli
Re: [PHP-DEV] WIP on extension loading improvement
On Tue, Apr 16, 2013 at 7:55 PM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Apr 16, 2013 at 7:06 PM, Julien Pauli jpa...@php.net wrote: Hello, I recently worked on the extension loading system to fully understand it and try to improve it while keeping full BC. Joe helped me in this task. I wrote an RFC giving details about what we have today ( https://wiki.php.net/internals/extensions ) The branch can be found here : https://github.com/jpauli/php-src/tree/extensions_improvements As I plan to merge it against master and probably 5.5 (not sure, depend on time), From a time point of view, and as RM you know it, I'd to say no for 5.5, too late for such changes. Yeah, I've been a little bit too hungry for this ;-) Julien.Pauli
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2013/4/12 Pierre Joye pierre@gmail.com: On Thu, Apr 11, 2013 at 11:17 PM, Pierrick Charron pierr...@adoy.net wrote: Including 5.3 and 5.4 ?? If removed in 5.3 and 5.4, theres no need for the constant anymore. Right :-) I agree with Pierre as well, we know this feature leads to bugs, is experimental, and is so not very very used. Julien.Pauli
Re: [PHP-DEV] Extension loading improvements
On Wed, Apr 10, 2013 at 7:14 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, 1) I didn't get why do we need fprintf(Loaded/Unloaded extension). It'll break all the tests in DEBUG mode 2) zend_error() may work through SAPI handler (e.g. for FastCGI sapi it may try to send error message to WebServer while request context is not initialized yet). I think it must work now, but should be double checked. After several tests on CLI and CGI, I see no bug, but starting cgi makes the error message being printed twice : */tmp/bin/php-cgi -dzend_extension=foo.so -dtrack_errors=1* *PHP Warning: /tmp/lib/php/extensions/debug-non-zts-20121212/foo.so doesn't appear to be a valid Zend Engine extension* * in Unknown on line 0* *Unknown(0) : Warning - /tmp/lib/php/extensions/debug-non-zts-20121212/foo.so doesn't appear to be a valid Zend Engine extension* * * *PHP Warning: /tmp/lib/php/extensions/debug-non-zts-20121212/foo.so appear to be a PHP extension, try to load it using extension=foo.so* * in Unknown on line 0* *Unknown(0) : Warning - /tmp/lib/php/extensions/debug-non-zts-20121212/foo.so appear to be a PHP extension, try to load it using extension=foo.so* * * Julien.Pauli
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Fri, Apr 12, 2013 at 4:09 PM, David Soria Parra d...@php.net wrote: On 2013-04-12, Johannes Schlüter johan...@schlueters.de wrote: 5.3 users might depend on some part of the behavior and have learned to live with bugs. We shouldn't kick features at this stage. curlwrappers should definatly stay in 5.3 and 5.4. I have no problem with having them removed in 5.5 (with an RFC) but I prefer to have it done before beta4 as this is going to be our last beta. Removing it in RC phase would bend the meaning of stages in the release process even more. Right, as Pierrick already got a patch, I asked him if he could write an RFC. We dont need a too big RFC, it's mainly about removing the feature to a feature-branch. Julien.Pauli
Re: [PHP-DEV] Extension loading improvements
On Wed, Apr 10, 2013 at 7:14 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, 1) I didn't get why do we need fprintf(Loaded/Unloaded extension). It'll break all the tests in DEBUG mode Great catch 2) zend_error() may work through SAPI handler (e.g. for FastCGI sapi it may try to send error message to WebServer while request context is not initialized yet). I think it must work now, but should be double checked. Thanks. Dmitry. Ok, Do you think as well we could build specific tests for this part ? We could pre-build some shared objects with different known behavior, and test for loading extensions and Zend extensions for example. Julien.Pauli
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Wed, Apr 10, 2013 at 6:52 PM, Pierre Joye pierre@gmail.com wrote: On Wed, Apr 10, 2013 at 6:46 PM, Julien Pauli jpa...@php.net wrote: Beta3 has been taggued with curl wrappers, and with the new CURL_WRAPPERS_ENABLED constant :-p Do we all agree to remove that feature (meaning moving it to a branch, or somewhere for the interested developers to keep on making it stable) for 5.5 stable or no ? I see no chance to get it stable for 5.5, the PECL way is the right and when it is stable we can re consider it. Ok, too bad we taggued beta3 with it. I suggest we remove this feature when going RC so. Thx all, Julien.Pauli
[PHP-DEV] PHP 5.5 beta3 is here
Hi Internals, PHP 5.5.0 Beta 3 has been released for testing. It fixes some bugs against beta 2. You'll find details in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. Our next beta is planned for April 25th. At this time, we are thinking the next beta (4th) should be the last one. RCs will follow. Thanks to all people that worked on the project to make this beta available. Regards Julien and David
[PHP-DEV] New wiki article about our extension mechanism
Hello, I wrote (its not finished yet) a wiki sheet to detail how our extensions mechanism work. This is not about how to write an extension :-p but it shows how the engine loads extensions, how it calls different hooks from them, and what are the differences between Zend extensions and PHP extensions. As I got plans to propose an RFC to rewrite this part of the engine (mainly to improve it, make it even more easy to manage from a PHP userland POV, and clean it from old dusty stuff), this first point should help anyone with little or no knowledge about that part. As a human, I make mistakes :) Feel free to edit the wiki page and add fixes. Julien.Pauli
Re: [PHP-DEV] New wiki article about our extension mechanism
On Wed, Apr 10, 2013 at 4:51 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Wed, Apr 10, 2013 at 6:53 AM, Julien Pauli jpa...@php.net wrote: Hello, I wrote (its not finished yet) a wiki sheet to detail how our extensions mechanism work. [...] As a human, I make mistakes :) Feel free to edit the wiki page and add fixes. I can't seem to find the page.. do you have a link? Yes I just linked it to main. Its at https://wiki.php.net/internals/extensions Julien.Pauli
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Fri, Apr 5, 2013 at 8:54 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Fri, Apr 5, 2013 at 7:14 AM, Julien Pauli jpa...@php.net wrote: On Fri, Apr 5, 2013 at 12:51 PM, Johannes Schlüter johan...@schlueters.de wrote: On Fri, 2013-04-05 at 08:01 +0200, Pierre Joye wrote: stream_wrapper_unregister(http); stream_wrapper_register(http, CurlStreamWrapper); and then stream_wrapper_restore(http) to go back to the core streams. I wonder what one will do with open streams during the switches. That can't go well. For open streams there should be no issue - they hold the pointer to their respective implementation. The issue I see is that libraries might change that for whatever reasons and not fix it up before passing control to some other library, thus creating a hardly debugable mess. I'm feeling like we wont be able to make it stable for 5.5 final. Right, I don't think its worth actually fixing this for 5.5, the current experiment should be removed by 5.5 and then the possibility to register the curl stream wrapper from userland could be introduced in 5.5.1 for example. For now, simply removing the config switch would be the quickest way to achieve progress with minimal changes back and forth if anyone wants to make that class. Beta3 has been taggued with curl wrappers, and with the new CURL_WRAPPERS_ENABLED constant :-p Do we all agree to remove that feature (meaning moving it to a branch, or somewhere for the interested developers to keep on making it stable) for 5.5 stable or no ? Julien.Pauli -Hannes
[PHP-DEV] Extension loading improvements
Hi all, Here are two branches that improve extension loading mechanisms and remove dusty old features not used any more. No BC or nothing, though perhaps some Windows support tricks to add ? Thoughts ? https://github.com/jpauli/php-src/extensions_improvementshttps://github.com/jpauli/php-src/compare/extensions_improvements https://github.com/jpauli/php-src/tree/remove_old_php4_dl Julien.Pauli
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Fri, Apr 5, 2013 at 8:01 AM, Pierre Joye pierre@gmail.com wrote: On Thu, Apr 4, 2013 at 9:52 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Its not only about maintaining it. This experiment failed a long time ago. Overwriting the core streams has proven itself to be the wrong way. I cannot agree more. If there was a way for userspace to say overload with curl then thats fine. We already have a procedure for this: stream_wrapper_unregister(http); stream_wrapper_register(http, CurlStreamWrapper); and then stream_wrapper_restore(http) to go back to the core streams. I wonder what one will do with open streams during the switches. That can't go well. Hey, that's true, we may meet strange behavior. I would say, why not create a new wrapper protocol, aka curl://. I know it is more ugly than http://; , but curl:// solves the problem doesn't it ? I wonder how we could use curl other protocols than http using curl:// though :p Julien.P
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
On Fri, Apr 5, 2013 at 12:51 PM, Johannes Schlüter johan...@schlueters.dewrote: On Fri, 2013-04-05 at 08:01 +0200, Pierre Joye wrote: stream_wrapper_unregister(http); stream_wrapper_register(http, CurlStreamWrapper); and then stream_wrapper_restore(http) to go back to the core streams. I wonder what one will do with open streams during the switches. That can't go well. For open streams there should be no issue - they hold the pointer to their respective implementation. The issue I see is that libraries might change that for whatever reasons and not fix it up before passing control to some other library, thus creating a hardly debugable mess. I'm feeling like we wont be able to make it stable for 5.5 final. Why not extract the code to pecl, make it stable if possible, then use it as a pecl extension ? It could also be merged to ext/curl in some way , that could be another option. Julien.Pauli
[PHP-DEV] Removing old pre_41 zend_module_entry struct checks while loading exts
All is into the title. A patch can be found here https://github.com/jpauli/php-src/compare/remove_dl_php4_support The idea is to get rid of those old stuff, like we did with session.compat some time ago. If you have ideas, improvements ... Joe also talked about adding a header to the zend_module_entry struct, to prevent us from hacking dl() like its been done for pre41. Kalle also talked about a way to make extension load in a particular order, the RFC is here : https://wiki.php.net/rfc/extensions_load_order Julien.Pauli
Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
IMO , we should remove that feature from 5.5. If Laruence is OK to maintain it, then we keep it, but Laruence, please, improve it so. We keep it if Laruence can make it stable for 5.5 final. If he cant , or doesn't want to work on it any more while in betas ; then we should remove curlwrapper from 5.5. Laruence: If you (or someone else) are motivated to work on it and feel all right to turn it to a stable feature without breaking streams or other stuff , then we will discuss a way to detect it. Why not parse the configure options by adding a new way to do it ? I'm writing a mail about that now. Thanks. Julien.P
[PHP-DEV] Adding a way to retreive compile options at runtime
Hello everybody, Today we talked about a way to detect --with-curlwrappers at runtime. It is nowadays not possible easilly. Then , I remembered I once proposed to add a new function that could return every ./configure options used to compile the runtime PHP the code is beeing run on. We already have php-config --configure-options, but that needs to exist and that needs an exec() call. We also already have phpinfo() which returns that, but not in a very fancy way (we need to preg_ the output which is ugly and not very simple). Today, Seldaek proposed what I think is a cool way to solve this problem : add a new parameter to phpinfo() function, which could return in an array what it usually directly print throught the SAPI print() function (HTMLing the output when needed). The use case would be : ?php $output = phpinfo(INFO_GENERAL, true); var_dump($output); /* something like ['Debug Build' ='no', 'Thread Safety'='yes', 'Configure Command'=['--enable-foo', '--with-config-file-scan-dir'='/etc' ]] As you can see, it is rather simple but would need some work as it is better for the Configure Command to return an array with the options instead of a big string ; easier to parse. Thoughts ? Julien.Pauli
Re: [PHP-DEV] Re: Adding a way to retreive compile options at runtime
The main use case was the topic about --with-curlwrappers from Laruence few days ago. Actually, for this use case , there is no way to detect if PHP's been compiled with --with-curlwrappers or not. The only way to detect this at runtime is to open a socket, then stream_get_metadata() onto it. Some code in the well-known Composer project, from Seldaek, uses ugly hacks, see https://github.com/composer/getcomposer.org/blob/master/web/installer#L135-148 Same for --enable-sigchild , the use case is here : https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Process/Process.php#L1061 After some reflection, we could find other ./configure options which cant be detected at runtime without parsing the phpinfo() output. For example, one may need to know if --enable-zend-signals h'as been enabled or not, for playing, say, with ext/pcntl I can write an RFC about this if needed, just wanted to get some thoughts before :-) Julien.Pauli On Thu, Apr 4, 2013 at 8:35 PM, Joe Watkins krak...@php.net wrote: On 04/04/2013 07:04 PM, Kris Craig wrote: On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins krak...@php.net wrote: On 04/04/2013 06:30 PM, Johannes Schlüter wrote: Joe Watkins krak...@php.net wrote: Many extensions do not provide constants or functions to detect the way they are configured, this may or may not expose those options, which is better than not being able to expose those options by any reasonable means. Then those extensions should expose the required information. These are bugs then. More importantly, it does not only contain information about extensions, or which extensions are loaded and how ( I am aware of the problems of using this kind of information as authoritative, I still say something is better than nothing, see every 404 page in all modern browsers, why not provide suggestions, even if they are wrong ). Path information I figure could be useful while setting up software, so The paths set during configure time don't have to match those where things are installed. Especially admins might prefer to use symlinked paths for configuration and users might be misled. could many other configure time options, for example if more than one SAPI was built at configure time, you might advise the use of the most suitable SAPI for your software, SAPIs might be built individually. Having them enabled during configure time doesn't mean they are enabled or accessible by the user. you might generate an ini file and tell the user where to put it (scandir), you might have the abnormal path to php-config or other things distributed with php and installed in a non-standard path (/opt/php-nts in example output). configure options often won't tell- There's a bunch of useful stuff in the configure command ... not just extensions loaded ... Yes and a lot of wrong information. johannes A combination of ENV, ini, phpversion and phpconfopt options should allow you to make much more informed decisions or do nothing at all, there is not a reasonable means to acquire this information, nor is it reasonable to suggest that we modify every single bundled extension in order to expose their configuration options, additional constants and maybe add new functions/methods. I keep using the words could, might, maybe, *on purpose*, I am aware that the configuration time options may not match runtime parameters, I don't think it falls to us to provide the business logic, so it doesn't really matter that the setup may be completely different, it may be the same, or similar. It may be vital information, it may also be completely irrelevant, exposing it provides more flexibility than doing nothing at all. Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I don't see any useful production applications for this. However, I could say the same thing about phpinfo() itself. From a debugging and QA standpoint, on the other hand, this could be potentially useful. If, for example, I was writing some sort of server analysis or troubleshooting utility, it might be helpful for me to be able to grab the configure command (or anything else in phpinfo(), for that matter) without having to do a screen scape. So even though the use case for this is somewhat narrow, I think it's something we should have in place, anyway. You should definitely write an RFC for this. --Kris I can't think of anywhere it's definitely useful, but I can think of many places it might be, combined with the right logic, and other things from environment/runtime/info etc ... There's probably one or two server analysis tools in production out there :) Hopefully, jpauli is still okay to move forward with an RFC, if the implementation is any good ... Writing bits of code, good fun, these long drawn out conversations and those that are the result of RFC creation ... not so much
Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module
Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter johan...@schlueters.dewrote: Hi, with opcache being bundled I expectr to see multiple bugs like #64568 where users are trying to load opcache as PHP module (using extension= in php.ini), I tried to improve the error message a bit. In https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c the PHP module loader will, in case of an error, check for Zend Extension symbols and give a more verbose error . Any opinions on this? +1, I like it Julien.Pauli
[PHP-DEV] PHP 5.5 Beta 2 is released
Hi Internals, PHP 5.5.0 Beta 2 has been released for testing. It fixes a bug that could prevent beta 1 from compiling, and other bugs you'll find in the NEWS file. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. Our next beta is planned for April 11th. We'd like to thank all the contributors for this beta. Regards Julien and David
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
On Mon, Mar 25, 2013 at 3:53 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Mar 25, 2013 at 7:42 AM, Dmitry Stogov dmi...@zend.com wrote: Hi, We are going to release a new PECL version today or tomorrow, 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. In order to maintain the PECL extension, do you plan to keep the bundled ZO+ code and the PECL code fully in sync? Just saw this commit http://git.php.net/?p=php-src.git;a=commitdiff;h=987dee9ca1be517f4be02d9c8f721d569596dc5aand wondered whether we really need all those version specific #ifs in the bundled version. I though getting rid of the code specific to old versions was a major selling point for the inclusion (= easier maintenance). Nikita Well, the plans should be that actually we just ship Zend Opcache within the PHP sources. Sure, those sources are the same as the PECL ones, like we do with all other bundled extensions (except some, like PDO). Correct if I'm wrong. All the #ifs about versions will be cleaned for 5.6, where we should plan a full integration (meaning merging ZOPcache within the Core code). Julien.Pauli
[PHP-DEV] PHP5.5 beta 1 is ready
Hi Internals, PHP 5.5.0 Beta 1 has been released for testing. As you know, this code base is shipped with Zend OPCache. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. Don't forget to activate Zend OPCache and test your code against it. Report any bug you could find. As you may know, we wont accept any new feature to come in 5.5 by now. Beta stage is meant to make the code base stable and pull a stable release from it. Our next beta is planned for April 4th. We'd like to thank all the contributors for this beta. Regards Julien and David
Re: [PHP-DEV] Enable Zend OPCache by default in php.ini-development during beta phase?
On Thu, Mar 21, 2013 at 4:02 PM, David Soria Parra d...@php.net wrote: Hi Internals, I added the default Zend OPCache settings to php.ini-development and php.ini-production atm. To have more people testing the opcache I would like to enable the OPCache in php.ini-development during the beta phase and disable it once we start the first RC. I hope we catch more errors with standard applications. As betas should not be used in production I think we won't have much problems with temporarly enable it. In case there are no objections I will commit this before beta 2. +1 Be carefull to pass the refresh param to 0sec for the script to be parsed every time. In dev env, one expects its script to be reparsed at every refresh or test. Julien.Pauli
Re: [PHP-DEV] Could we kill call_user_func?
On Tue, Mar 19, 2013 at 12:42 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Also, AFAIR, call_user_func() doesn't work with functions using references in args. Use call_user_func_array() for that, it supports refs. Isn't it since 5.3 or so ? Julien.Pauli
Re: [PHP-DEV] Could we kill call_user_func?
On Sat, Mar 16, 2013 at 7:51 AM, Sara Golemon poll...@php.net wrote:
${'_'.!$_=getCallback()}();
Well now, that's an... interesting abuse of resolution order and type
juggling.
Really crazy, yeah
Also, AFAIR, call_user_func() doesn't work with functions using references
in args.
Julien.Pauli
Re: [PHP-DEV] Could we kill call_user_func?
On Mon, Mar 18, 2013 at 3:33 PM, Anthony Ferrara ircmax...@gmail.comwrote: Angel, On 18/03/13 14:04, Julien Pauli wrote: Also, AFAIR, call_user_func() doesn't work with functions using references in args. Julien.Pauli AFAIK it does. Do you have an example where it doesn't? It definitely does not: http://3v4l.org/C8Kme And if you try call-time-pass-by-reference, it gets worse: http://3v4l.org/pI89l Yeah, that's what I remembered. call_user_func() is not exactly the same as calling the function, when references come to scene, it just wont work. Same with _array() implementation. Julien.Pauli
Re: [PHP-DEV] disable zend_always_inline in debug mode
On Fri, Mar 8, 2013 at 4:27 PM, Laruence larue...@php.net wrote:
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
I'm +1 with that.
Julien.Pauli
Re: [PHP-DEV] disable zend_always_inline in debug mode
I ran some benchs, on my current machine (wasnt isolated to run tests). I
ran micro_bench.php on master branch today :
debug on, inline enabled :
Total 30.688
debug on, inline disabled :
Total 35.377
debug off, inline enabled :
Total 10.130
debug off, inline disabled :
Total 10.678
Julien.Pauli
On Fri, Mar 8, 2013 at 4:32 PM, Julien Pauli jpa...@php.net wrote:
On Fri, Mar 8, 2013 at 4:27 PM, Laruence larue...@php.net wrote:
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
I'm +1 with that.
Julien.Pauli
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Thu, Mar 7, 2013 at 5:46 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 03/07/2013 08:26 AM, Pierre Joye wrote: That being said, if o+ would have 2/3 of the votes, I think it is possible to get it stable until 5.5 final, not easy but possible. We already covered that. An opcode cache doesn't affect the language itself. There is no new syntax and no BC issues. Much like a performance improvement patch that has no effect on the language syntax doesn't need 2/3. Whether it is major or not, doesn't matter per the established voting process. You can't both be a stickler for the details of this process and then ignore them when they become inconvenient for you. btw, I would even have included phar as affecting the language, as even if you don't use it at all in your code, it affects how php behaves. We had many issues related to phar while it was not used at all in the code (due to the hooks). That's not exactly the same thing than o+ but it has the same kind of possible impacts. And there comes the true definition of affects language behavior. We still don't agree each other of what a major change, and a minor one are, *and* : do we talk about user-level changes, or internals changes ? Or both ? That definitely needs to be clarified, or Anthony's idea of no distinction on any RFC and make them require 2/3 to be accepted as well. Julien.Pauli
Re: [PHP-DEV] Memory warning hook
One should try ext/memtrack http://pecl.php.net/package/memtrack Also ext/memprof https://github.com/arnaud-lb/php-memory-profiler/ Julien.Pauli On Tue, Mar 5, 2013 at 9:14 PM, nat...@starin.biz wrote: This is not the same at all. When are you going to run this code? Memory allocations happen all the time. What Nathan asked for is an event that is triggered when the memory consumption reaches a threshold. However, there is a different solution, which is better IMHO in the case of caches: weak references. A weak reference automatically frees the memory of the object, when the memory is needed. http://php.net/manual/en/book.weakref.php. Having said that, none of these solutions scale up to multiple servers. This is why shared cache systems like memcached are recommended. I agree this probably is a good solution and I personally do use it along with shared memory tools, however there may be cases where the dev may gain more benefit from having a memory-warning installable trigger in place. This would allow things like allowing the dev to release certain cache objects before others or something completely different that I have not thought of yet. Running the GC is most likely faster than most cleanup routines a user could run, also usually there is not that much stuff cached in PHP scripts. If a PHP script has tons of data, which it can easily throw away, in memory this sounds like a smell of an bad architecture. Cache cache-worthy stuff in memcache or such and fetch only the data you need. Also: What should happen if the system runs out of memory while doing the cleanup? Anything sane doesn't sound good either. Yes running the GC is much faster except they are two completely different processes... in my example the dev is keeping references to data for possible future use later on however it's not possible to know when to release these references so php's GC can collect them if the user does not implement something quite juristic like ticks or frequent function calls throughout a code base. You can use ticks :) http://php.net/control-structures.declare#control-structures.declare.ticks Yes Ticks are something useable (like said above) however I have found ticks are clunky, frequently shunned, and you'd be ticking for no reason most of the time. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
On Fri, Mar 1, 2013 at 11:39 AM, David Muir davidkm...@gmail.com wrote: On 01/03/2013, at 7:00 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hey all, Based off of the recent discussion around pulling in ZO+ into core, I've come to the conclusion that we should also pull in XDebug and Suhosin into core at the same time. 1. It has integration issues with ZO+ in that it has to be included in a specific order (specifically around ini declarations). If it was included into core, this could be accounted for allowing for more robust behavior. 2. Both to be maintained for each new language feature as well as opcode-caches. This will have the same benefit as integrating ZO+, as it can be maintained inline with the engine. 3. Both stand as a barrier to adoption as many will not run PHP in development without XDebug, and they won't run it in production without the Suhosin patch. Since both of these are vital to PHP's uptake and adoption of new versions, I feel it's important to delay 5.5 until we can get both in. I can draft up the RFC if necessary... Anthony Nice :-P Seriously though, what's the deal with the Suhosin patch? I use it because it's included by default on Ubuntu... Didn't know about the huge performance impact. Their website seems to imply that PHP has security holes that have never been patched, and are only closed by using Suhosin. I find that hard to believe. Is PHP really *that* vulnerable without it? The site (http://www.hardened-php.net/suhosin/) is somewhat light on details. Any computer system is vulnerable as far as you press the start button and plug in the network cable ;-) Julien
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
On Thu, Feb 28, 2013 at 9:13 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! Based off of the recent discussion around pulling in ZO+ into core, I've come to the conclusion that we should also pull in XDebug and Suhosin into core at the same time. Suhosin has multiple BC-incompatible and performance-problematic changes and limits and the author refused many times to work with PHP team. I'm not sure how we could pull extension that the author of it isn't interested in working with PHP group. +1 1. It has integration issues with ZO+ in that it has to be included in a specific order (specifically around ini declarations). If it was included into core, this could be accounted for allowing for more robust behavior. I'm not sure what you mean about ini declarations, could you expand on this or refer me to the place where it is explained? I guess the ini declaration order and then the order the modules get loaded in the engine. Julien
Re: [PHP-DEV] I would like to write an RFC for the addition of an internal keyword
On Thu, Feb 28, 2013 at 12:40 PM, Lazare Inepologlou linep...@gmail.comwrote: Hello, please read my comment inline... 2013/2/28 Sebastian Krebs krebs@gmail.com 2013/2/28 Jens Riisom Schultz ibmu...@me.com Hi everyone, (I got hooked off this discussion, so I have tried to keep up by reading the digest... This makes it impossible for me to correctly interleave my comments, so I'll just top post or whatever the term is) (I'm sure this has been mentioned before but a forum would be so much more accesible than this mailing list concept...) * In response to the argument that you want to be able to modify a framework or use it in an unintended manner: This would be possible by explicitly stating namespace Framework; in a given php file. * In response to the argument that php has no assembly concept: I know this, but namespaces are as close as we get, and would effectively solve this. No. A namespace is in fact more or less just a prefix, that groups the containing elements together. Beside the semantic meaning of grouping they don't have any further abilities, or meaning. Without knowing exact details I guess, that internal in C# is primary a technical thing, that allows a compiler further optimizations, because he definitely knows, that the function/method is only used within the assembly and is not required to do anything to expose it to the outside? Regardless of the technical details, it is still a fine way of applying encaptulation so you can't say that it is only a technical thing. * In response to the argument that php already has accessibility restrictions with private and protected: This is true, but it does not solve all problems. Often you need classes to interoperate in a way that can only be facilitated by making functionality public. Also, there is no way to make a private or protected class (since php has no assembly concept), though what I propose would likely birth the concept of private and protected classes as well. Maybe it's just me, but no: I've never had the need of what you describe and where a public method wasn't apropriate anway... At least for a very long time :D * In response to the argument that PHP does not restrict anyone from adding to a namespace: That is true, but say you were using Doctrine2. Would you ever make a php file with namespace Doctrine2; in it, unless you wanted to modify Doctrine2, and hence you knew what you were doing, or accepted the risks? Well, yes. But extending/overriding a components method _always_ requires, that you know what you do, so why enforcing/encouraging hacks, instead of the good old protected? Protected is used for extending classes. There is no mechanism to inherit and extend a namespace so protected is irrelevant here. * In response to the concept of solving this through documentation: First off, this is not possible with the current phpdoc and phpdoc2 standards. Second off, problems like these should not be solved by documentation, imho, or of course I would not propose this. The C# designers seem to agree with me. And the Java designers, too (though they have no internal keyword they do have a way of hiding framework specific classes). Actually Java has a concept that is identical to your proposal. The default access modifier (when no access modifier is written) is the package modifier (=accessible from within the same package). Ha, it's been years since I'm asking for such a feature to come to PHP. I would love to see a package visibility in PHP, restricting access to 'package'ed members (methods or attributes) to an object born from a class of the same namespace. Would really help some cases in frameworks or so :-) Just my2cents Julien
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
On Fri, Mar 1, 2013 at 12:49 PM, Kalle Sommer Nielsen ka...@php.net wrote: Hi 2013/3/1 Julien Pauli jpa...@php.net: I guess the ini declaration order and then the order the modules get loaded in the engine. We could also look at implementing a module-load-order internally in the zend_module struct, as in some extensions like EXIF relies on mbstring, while the ZEND_MODULE_DEP()s works fine for checking for mbstring, it does not work if mbstring is loaded after. So what I'm saying is that mbstring have a higher load order, meaning even though we have this in php.ini[1], PHP will load mbstring first because it has the lowest value (requiring it to start first), or giving exif a higher than 'normal' value (causing it to load after, as it is after all, exif that depends on mbstring, not the other way around). The same thing can be done with engine level extensions (zend_extension), where it probably would make more sense than for 90% of all 'php' extensions. [1]: extension=php_exif.dll extension=php_mbstring.dll +1 , Some time ago when I first designed my first extensions studying the Zend extension loading mechanism I thought about such a system and was surprised not to find one into the engine. It shouldn't be too hard to develop, except if you start thinking about versions dependencies of the modules as well. In the same pipe, I was thinking at some dlunload() function which would enable unoloading modules at runtime, but that's another task, not very trivial though. Julien -- regards, Kalle Sommer Nielsen ka...@php.net
[PHP-DEV] PHP 5.5 alpha 5 is released
Hi Internals, PHP 5.5.0alpha5 has been tagged and released. This release contains bug fixes against alpha4, and adds new features in the mysqli and mysqlnd API, new HTTP codes and the possibility to change the temp directory using a php.ini directive. The packages can be found at: http://downloads.php.net/dsp As you know, you may read the NEWS file in the source tree for full changelog of this release. Please test PHP5.5.0alpha5 carefully, and report any bugs in the bug system. We may begin now the beta stage of 5.5.0. As you should know, we had a delay for beta due to some late coming features such as Zend Optimizer +. Please, be warned that the first beta will be the last release for you to add new features. After first beta, features will get frozen, next betas won't accept new features and should focus on consolidating the code against bugs. The first beta should be tagged on March 7th. Thank to all the contributors that mainly gave their time to make this alpha5 possible. Regards David and Julien
[PHP-DEV] PHP 5.5 upcoming roadmap
Hello everyone, As you may know, Zend recently open sourced ZendOptimizer+ with a PHP Licence. We are planning to merge it to PHP5.5 Core (discussions on Mailing lists and IRC) and have it bundled with PHP5.5 final release stable. For this, we need to merge new code to 5.5 as well as have a testing period for this new feature. As RMs, David and I decided then to change the original release plans for 5.5. 5.5 will benefit a new alpha (5th), on thu 21st Feb. ZO+ will be merged for this alpha. Then, we are planning to release the first beta on March the 7th. We remind you that beta stage means feature freeze. We won't accept new features code after the first beta is released. This is a (about) one month delay compared to original planning (first beta was planned for Feb 7th), but it is needed. You will find more information about ZO+ integration on the wiki, at https://wiki.php.net/rfc/optimizerplus Julien Pauli and David Soria Parra
Re: [PHP-DEV] File system watcher/monitoring
On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net wrote: Hi internal, A missing feature in PHP is a file system watcher/monitoring available for almost all platforms. On Linux, we have inotify (available in PHP through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All major platforms have a solution ready to use. By now, if we didn't use these solutions, we should use a finder (thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n seconds and compute a diff with the previous run. This solution works fine for a small set of files but it can slow for a big one. This is just a tricky solution, not a proper one. Possible domains where it is needed: test, CI, log, file transfering, security etc. Is it possible to have such a feature landing in PHP (core if karma allows it)? or do you want such a feature? Best regards :-). Hello :-) I don't see why we would have such a thing into PHP Core. We are already smooth about the file system accesses with a realpath cache, and users may use different pecl ext if they want to take hand on a lib such as inotify. Julien
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 5:32 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/14/2013 11:21 AM, Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500): On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Hmm. I was loading them the other way around, but did not encounter any interesting problems yet... Most things work fine, but I hit a weird segfault in some complicated code which I fixed by flipping the order. Shouldn't we document that, or add some notice at extension loading by detecting Xdebug ? Julien.Pauli
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara ircmax...@gmail.comwrote: Pierre et al, I would prefer to have it in pecl and merge once ready/cleaned up. Yes, same idea than with APC, except that it could be faster (for what I read, waiting to see the sources). Also we can review and do the changes more easily. Well, I think the one issue with doing it in PECL first is that it prevents some deeper engine integration that could benefit the implementation significantly. With that said, I think it's a bit too tight to try to merge this in for the 5.5 beta freeze. Given the current RFC process requires a minimum of 2 weeks (1 of comments and 1 of voting), it feels tight. I'm not saying that I think we should stick to the numbers hard in this particular case, but it's also not a trivial patch, and I feel that rushing wouldn't be the best idea. So with that said, may I suggest that we add 1 more round of Alpha to the 5.5 release cycle, with the specific intent of merging this in (assuming the implementation goes well). So we'd be talking about adding approximately 2 weeks to the cycle, but it would ease the time and implementation pressures that could otherwise cause issues. I think this feature is worth pushing 5.5 back slightly, but at the same time not delaying it indefinitely until this gets in. So if in 4 weeks (the time until the beta, under this strategy) this isn't ready, it wouldn't make 5.5. But at the same time it gives us enough time to implement it, understand the implementation and make a decision that's based on a concrete implementation than an in-progress one. Thoughts? I'm ok with that, that's safe and clean :) Julien.P
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 01/24/2013 11:56 PM, Ralf Lang wrote: From what I understood from Rasmus the biggest challenge with merging APC into core is the fact that the compiler currently isn't built to support opcode caching. One of the challenges he pointed out was some of the MAKE_NOP trickery that can make APC's work a bit more complex than necessary. It's possible to optimize the compiler enough to the point that APC's code could be reduced down to very simple opcode caching, putting less stress on the engine and making it easier to maintain. I think there was some support for moving APC first from pecl to the PHP standard distribution's ext folder before any tighter integration is started. I'm really not convinced that by moving it to core we will magically get people to help with it. I have been trying to get people interested for years, and it hasn't gotten very far. Everyone wants it in the core, but with a couple of exceptions, nobody is willing to actually work on it to get it there. And I can understand the lack of help. It is probably the most complicated piece of the entire stack. It is a an op_array juggler doing a complex dance on a tight rope backwards and blindfolded. It is essentially multi-threaded in that there are multiple processes all reading and writing the same chunk of memory while dealing with a compiler that spits out context-sensitive op_arrays that were never designed to be cached and executed this way. So the learning curve is steep and the bugs are extremely hard to track down because it is the only PHP component that isn't a perfect sandbox. A slight memory corruption almost anywhere in any extension can segfault a dozen requests later with a backtrace that points to the opcode cache code. Not to mention web servers like Apache that longjmp() on us at the wrong time. Zend-signals addresses this, but even in 5.4 they aren't enabled by default because of stability issues and without those no shared memory opcode cache is safe. I firmly believe that we need opcode caching in core. I'm rather skeptical that simply moving pecl/apc to ext/apc is going to help users in any way. People have no trouble finding and installing APC today. The real issue here is robustness and lag time between a PHP release and and solid APC release and that has to do with resources which are scarce due to the code complexity. This is the real problem we need to solve. Either by a number of people stepping up to help with the existing APC code, or perhaps more realistically making it a priority in PHP 5.6 to streamline the engine and the executor for opcode caching and either including a heavily simplified version of APC or writing a new one. That feels like a safe idea. I'm convinced that having more internals documentation will help developpers understand at least the engine (that's what interest us here). I know it's a hard task, but we all here have blogs where sometimes we write great articles about a part of internals, I think we should focus on working alltogether writing a real technical doc for the engine, that will help people (like me for example), understand some dark parts of it, and then find ideas or solutions for it to evolve the right way. One thing I can guarantee is that if we add it to core in its current condition it will delay 5.5 by 6+ months if not longer. Ok that seems clear. Julien.Pauli
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch willfi...@php.net wrote: On Jan 25, 2013, at 11:25 AM, Zeev Suraski z...@zend.com wrote: Either by a number of people stepping up to help with the existing APC code, or perhaps more realistically making it a priority in PHP 5.6 to streamline the engine and the executor for opcode caching and either including a heavily simplified version of APC or writing a new one. One thing I can guarantee is that if we add it to core in its current condition it will delay 5.5 by 6+ months if not longer. There's another option. We have the Optimizer+ component which is current, a bit faster than APC, worked with PHP 5.4 from the get go and already fully supports 5.5 - and now that it's been free for use for several years, we'd actually be happy to opensource it and make it a part of core. An extra benefit would be that we'd commit to maintain it, although of course, community contribution will be very welcome. Here too, it's code with a very long history, some of which even predates PHP 4.0. But It Works(tm), and we could put some effort into cleaning it up and beautifying it. I like the idea. If this was implemented in core, and the need for APC opcode caching disappeared, would APC still be actively maintained for userland functions (e.g. apc_store, apc_*)? Well, the APC idea was anyway to merge an Opcode cache to Core, and only an Opcode cache (correct if I'm wrong). apc_store() etc... are userland shared memory function, and should be migrated into another extensions, on which we could then allocate devs to work on, new ideas, etc... Julien.Pauli
Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Fri, Jan 25, 2013 at 8:05 PM, Pierre Joye pierre@gmail.com wrote: On Fri, Jan 25, 2013 at 7:53 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 01/25/2013 10:49 AM, Zeev Suraski wrote: Ok, I'll write up an RFC, and in parallel we'll try to figure out the mechanics of actually making it happen. Commit to master maybe and we can work on cleaning it up for the 5.5 branch. I would prefer to have it in pecl and merge once ready/cleaned up. Yes, same idea than with APC, except that it could be faster (for what I read, waiting to see the sources). Also we can review and do the changes more easily. -- 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 I think I can help on things as well. I'm really looking forward in seeing the source code. I guess it will be PHP licenced right ? Julien.Pauli
[PHP-DEV] PHP5.5.0alpha4 is ready for testing
Hi Internals, PHP 5.5.0alpha4 has been tagged today. This release contains bug fixes against alpha3, and adds the class name resolution via scalar and the DateTimeImmutable The packages can be found at: http://downloads.php.net/dsp As you know, you may read the NEWS file in the source tree for full changelog of this release. Please test PHP5.5.0alpha4 carefully, and report any bugs in the bug system. We may begin now the beta stage of 5.5.0. Please, be warned that now features are frozen, betas won't accept new features to be added and should focus on consolidate the code against bugs. The first beta should be tagged on February 7th. We would like to thank all the contributors that made this alpha4 possible. Regards David and Julien
