Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
Yes, it's a good idea ! Opcache + Usercache = perfect match ! Using Memcached is not efficient for storing lot of values (the TCP round trip cost). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
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. On Sun, Mar 24, 2013 at 12:54 PM, Pierre Joye pierre@gmail.com wrote: On Mar 24, 2013 2:25 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Would it be an idea to put several flavours of php_opcache.dll at http://windows.php.net/downloads/pecl/snaps/ These are quite 'old': http://windows.php.net/downloads/pecl/snaps/ZendOptimizerPlus/7.0.1-dev/ See the requests for such dll's at http://www.apachelounge.com/viewtopic.php?t=5242#24199 Yes, but it should be done using the pecl version, not the version in code. I did not follow the github's repository but as far as I can see none of the fixes in core has been back ported. If I am not mistaken the plan was to have the bundled version 5.5+ only (or for the given branch), and not to keep compatibility with older php versions. Dmitry, what do you think to try to keep releases via pecl and core in sync as long as it is possible? That means one/two years for 5.3, and 3-4 years for 5.4. Cheers, -- Pierre @pierrejoye
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
On Mon, Mar 25, 2013 at 2:42 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, We are going to release a new PECL version today or tomorrow, oh? okey, after you taged, I will do it. :) thanks and, yes, we are going to support hte pecl build for old versions as well. I'm not sure about php-5.2 and possible new features. Thanks. Dmitry. On Sun, Mar 24, 2013 at 12:54 PM, Pierre Joye pierre@gmail.com wrote: On Mar 24, 2013 2:25 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Would it be an idea to put several flavours of php_opcache.dll at http://windows.php.net/downloads/pecl/snaps/ These are quite 'old': http://windows.php.net/downloads/pecl/snaps/ZendOptimizerPlus/7.0.1-dev/ See the requests for such dll's at http://www.apachelounge.com/viewtopic.php?t=5242#24199 Yes, but it should be done using the pecl version, not the version in code. I did not follow the github's repository but as far as I can see none of the fixes in core has been back ported. If I am not mistaken the plan was to have the bundled version 5.5+ only (or for the given branch), and not to keep compatibility with older php versions. Dmitry, what do you think to try to keep releases via pecl and core in sync as long as it is possible? That means one/two years for 5.3, and 3-4 years for 5.4. Cheers, -- Pierre @pierrejoye -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
Hi Xinchen, I've merged all the changes from php and updated version to 7.0.1. Please make all the necessary package.xml modifications and set v7.0.1 tag yourself. Please, update me, when you are done. Thanks. Dmitry. On Mon, Mar 25, 2013 at 10:43 AM, Laruence larue...@php.net wrote: On Mon, Mar 25, 2013 at 2:42 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, We are going to release a new PECL version today or tomorrow, oh? okey, after you taged, I will do it. :) thanks and, yes, we are going to support hte pecl build for old versions as well. I'm not sure about php-5.2 and possible new features. Thanks. Dmitry. On Sun, Mar 24, 2013 at 12:54 PM, Pierre Joye pierre@gmail.com wrote: On Mar 24, 2013 2:25 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Would it be an idea to put several flavours of php_opcache.dll at http://windows.php.net/downloads/pecl/snaps/ These are quite 'old': http://windows.php.net/downloads/pecl/snaps/ZendOptimizerPlus/7.0.1-dev/ See the requests for such dll's at http://www.apachelounge.com/viewtopic.php?t=5242#24199 Yes, but it should be done using the pecl version, not the version in code. I did not follow the github's repository but as far as I can see none of the fixes in core has been back ported. If I am not mistaken the plan was to have the bundled version 5.5+ only (or for the given branch), and not to keep compatibility with older php versions. Dmitry, what do you think to try to keep releases via pecl and core in sync as long as it is possible? That means one/two years for 5.3, and 3-4 years for 5.4. Cheers, -- Pierre @pierrejoye -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
Le 25/03/2013 07:42, Dmitry Stogov a écrit : 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. Great news. I think it really makes sense to have ZO+ available for PHP 5.4. Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
On Mon, Mar 25, 2013 at 8:52 AM, Dmitry Stogov dmi...@zend.com wrote: Hi Xinchen, I've merged all the changes from php and updated version to 7.0.1. Please make all the necessary package.xml modifications and set v7.0.1 tag yourself. Please, update me, when you are done. we will provide windows builds as well as soon as the release is done. Thanks for your work! Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
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
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
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
Le 25/03/2013 06:47, Laruence a écrit : attached here: https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build_2.patchrevision=latest Tested under RHEL 6.4 (bison 2.4.1), Fedora 17 (bison 2.5) and Fedora 18 (bison 2.6.1). NTS and ZTS build OK. Thanks, Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OPcache precompiled dll's for older Windows versions
Hi, We didn't decide yet, if it's better to remove support for old versions in opcache bundled into php-5.5 or not. In general it should be removed but it would make maintenance of pecl branch more difficult. Thanks. Dmitry. On Mon, Mar 25, 2013 at 7:00 PM, Julien Pauli jpa...@php.net wrote: On Mon, Mar 25, 2013 at 3:53 PM, Nikita Popov nikita@gmail.comwrote: 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] Remove support for cloning generators
Hi internals! Now that we're in the beta phase I want to put some finishing touches on the generators implementation. The first thing I'd like to do is remove support for cloning generators. There are a few reasons for this: a) The cloning basically works, but the implementation is rather fragile and easy enough to break. I just had another look at the code and found two new ways to make it segfault. I could fix those issues, but I'm pretty sure that they are not the only bugs in there (that's in the nature of that code). b) Especially if objects are involved, the cloning can result in weird behavior. E.g. if a generator is cloned that makes use of an SplStack, after cloning both generators will make use of the same stack, which makes little sense. Just cloning all objects instead of just adding a ref doesn't make sense either, because cloning would be the wrong thing to do for objects passed as arguments. One would basically have to clone only objects created inside the generator, or something like that, which is not technically possible. c) Most importantly, there is very little use for the cloning. At first I thought it would be nice to use cloning in order to implement forking when using coroutines as a means of multitasking, but this doesn't really work well due to b). Apart from that I can think of no use for cloning at all. Patch for removing cloning is here: https://github.com/nikic/php-src/commit/805b244d8f106431f01b5c013d4e66f9bb88d09b If no one objects I'll commit it sometime soon. Thanks, Nikita
Re: [PHP-DEV] Re: Fix for #64450
Dmitry, after spending more time on this issue I came to the conclusion it shouldn't be touched :) . The __x86_64__ you've mentioned is solvable on compile time using a macros like this defined(PHP_WIN32) || ((defined(__i386__) || defined(__i386)) defined(__STDC_IEC_559__)) so either old or new variant would be activated. __STDC_IEC_559__ is a macros wintessing IEEE 754 conformity, so double can hold long on 32 bit. But another issue I've overseen is that the php_mt_rand() delivers in uint range, that's way too few if one wants to work with double as incoming type. There are also some other places like PHP_RAND_MAX which are incompatible. That isn't solvable with just touching the pt_rand function. At the end of the day seems there is no way around to get this issue properly working on both 64 and 32 bit platforms than implementing the Mersenne Twister for every applicable variation, effectively double or long. That might coexist in pecl or in core. Any other intrusion would change the core significantly. Thanks for your support! Anatol On Fri, 2013-03-22 at 11:34 +0100, Anatol Belski wrote: On Fri, March 22, 2013 10:08, Dmitry Stogov wrote: Thanks, now I understood. :) anyway I see a problem. For example on x86_64 double is not always able to keep a long number without precision lost. May be you should receive arguments as zvals and use old or new code depending on input types. Damn that's right, I've just read this page http://www.viva64.com/en/a/0004/#ID0EQ3BI double is on both x64 and x86 64 bit, but effectively 52 bits used for the integer part. My patch would work on 32 bit Linux and both x86 and x64 windows, but would fail on x64 Linux/unix systems. I have to come up with a better solution to do this check on compile or (more likely) on run time. BTW: I'm not sure if rand() should be fixed at all. According to http://php.net/manual/en/function.rand.php it should accept integers and return integer. Yep, formally it's documented. De facto users meet that issue and that could indeed be made better, that's my motivation. Thanks for the tips. Anatol Thanks. Dmitry. On Fri, Mar 22, 2013 at 12:08 PM, Anatol Belski a...@php.net wrote: Dmitry, first of all thanks for taking a look :) The issue in a few words - mt_rand reads arguments as long - user pass a float from the userspace - zend_parse_parameters with 'l' casts to long Here's the essential snippet echo mt_rand(0,pow(10,12)); PHP Warning: mt_rand(): max(-727379968) is smaller than min(0) So reading as long would probably not work, in the first place because the input data exceeding LONG_MAX will be corrupted by the conversion. So what I did - read input as max precision possible, no corruption - calculate as well with double - return the old way int if it's in LONG_MAX range, otherwise return float Is there a solution I don't see (or do I get your suggestion wrong)? It's just essential to get the input as precise as it can be across PHP. Besides that what could be impacts changing input arg types in this concrete case? User probably wouldn't realize that at all. Thanks Anatol On Fri, March 22, 2013 07:40, Dmitry Stogov wrote: Hi Anatol, To be honest, I didn't understand all the details of the patch :) However, I see a problem: You changed the prototype of user level rand() function to receive double arguments instead of long. I think it's disallowed, but you may get arguments as longs and then convert them to double. Will it work? Thanks. Dmitry. On Thu, Mar 21, 2013 at 9:26 PM, Dmitry Stogov dmi...@zend.com wrote: I'll able to look only tomorrow morning. Thanks. Dmitry. On Thu, Mar 21, 2013 at 8:46 PM, Anatol Belski a...@php.net wrote: Hi Dmitry, I developed a patch for this one https://bugs.php.net/bug.php?id=64450 . It's regarding to the long overflow in mt_rand(). The main idea is to work with the args as double internally and then return php float if it exceeds the LONG_MAX. I strived to let the old behavior to be unchanged, all the older tests pass. Please take a look. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On Mar 6, 2013 4:51 PM, Nikita Popov nikita@gmail.com wrote: I'd prefer to have nothing over having something bad. +1 Can we fix this issue, please? Nikita Mike
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On 03/25/2013 08:41 AM, Remi Collet wrote: Le 25/03/2013 06:47, Laruence a écrit : attached here: https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build_2.patchrevision=latest Tested under RHEL 6.4 (bison 2.4.1), Fedora 17 (bison 2.5) and Fedora 18 (bison 2.6.1). NTS and ZTS build OK. Thanks, Remi. Bison 2.3 with Oracle Linux 5.9 (and therefore with RHEL 5.9) gives this error: /home/cjones/php-5.5/Zend/zend_language_parser.y:50.1-5: invalid directive: `%code' /home/cjones/php-5.5/Zend/zend_language_parser.y:50.7-14: syntax error, unexpected identifier [You can get Oracle Linux (and keep up to date with patches and security errata) from http://public-yum.oracle.com/] Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On 03/25/2013 01:43 PM, Christopher Jones wrote: Bison 2.3 with Oracle Linux 5.9 (and therefore with RHEL 5.9) gives this error: /home/cjones/php-5.5/Zend/zend_language_parser.y:50.1-5: invalid directive: `%code' /home/cjones/php-5.5/Zend/zend_language_parser.y:50.7-14: syntax error, unexpected identifier [You can get Oracle Linux (and keep up to date with patches and security errata) from http://public-yum.oracle.com/] I'm ok dropping bison-2.3 support from 5.5. We ship a generated parser, so this only affects people who need to re-generate the parser for some reason and the people who need to do that are more than capable of installing a more modern Bison. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On 03/06/2013 10:50 AM, Nikita Popov wrote: I'd prefer to have nothing over having something bad. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5.5 beta 1 is ready
On Sun, Mar 24, 2013 at 3:48 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Mar 24, 2013 at 3:06 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Mar 23, 2013 at 5:02 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Mar 23, 2013 at 4:53 PM, Derick Rethans der...@php.net wrote: On Thu, 21 Mar 2013, Julien Pauli wrote: 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. I'm having issues with installing PEAR: Saving to: ‘pear/install-pear-nozlib.phar’ 100%[==] 3,692,810 6.27MB/s in 0.6s 2013-03-23 15:51:04 (6.27 MB/s) - ‘pear/install-pear-nozlib.phar’ saved [3692810/3692810] [PEAR] Archive_Tar: could not extract the package.xml file from phar://install-pear-nozlib.phar/Archive_Tar-1.3.7.tar [PEAR] Console_Getopt: could not extract the package.xml file from phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar [PEAR] Structures_Graph: could not extract the package.xml file from phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar [PEAR] XML_Util: could not extract the package.xml file from phar://install-pear-nozlib.phar/XML_Util-1.2.1.tar [PEAR] PEAR: could not extract the package.xml file from phar://install-pear-nozlib.phar/PEAR-1.9.4.tar And hence, I have no pecl or pear binaries installed. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php http://www.mail-archive.com/internals@lists.php.net/msg62946.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu I think I've fixed the problem and sent a PR to the PEAR guys ( https://github.com/pear/pear-core/pull/12 btw. there were already a PR for this: https://github.com/pear/pear-core/pull/10 I just didn't noticed until I've sent mine), hopefully they merge it soon, if not we can still build our self and upload it somewhere and change the pear/Makefile.frag to wget that version. Sherif also confirmed that the phar file produced by the patched pear script results in a working pear install. We have http://php.net/63073 to track an issue on our part and I also opened a bug on pear.php.net just to be sure that it won't be forgotten this time: https://pear.php.net/bugs/bug.php?id=19867 -- Ferenc Kovács @Tyr43l - http://tyrael.hu The pear guys(Daniel O'Connor, Christian Weiske to be precise) merged the PR and rebuilt the phar install-pear-nozlib.phar and install-pear-nozlib.phar files, so the issue should be resolved, please report if you still experience pear installation problems with php 5.5.
Re: [PHP-DEV] Questions regarding DateTimeImmutable
So how do we officially undo something that didn't use an RFC but should have?
Re: [PHP-DEV] Questions regarding DateTimeImmutable
Am 25.03.2013 um 21:23 schrieb Sebastian Bergmann sebast...@php.net: On 03/06/2013 10:50 AM, Nikita Popov wrote: I'd prefer to have nothing over having something bad. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On 03/25/2013 01:59 PM, Rasmus Lerdorf wrote: On 03/25/2013 01:43 PM, Christopher Jones wrote: Bison 2.3 with Oracle Linux 5.9 (and therefore with RHEL 5.9) gives this error: /home/cjones/php-5.5/Zend/zend_language_parser.y:50.1-5: invalid directive: `%code' /home/cjones/php-5.5/Zend/zend_language_parser.y:50.7-14: syntax error, unexpected identifier [You can get Oracle Linux (and keep up to date with patches and security errata) from http://public-yum.oracle.com/] I'm ok dropping bison-2.3 support from 5.5. We ship a generated parser, so this only affects people who need to re-generate the parser for some reason and the people who need to do that are more than capable of installing a more modern Bison. -Rasmus OK. I also tested bison 2.7. After locally patching Zend/acinclude.m4 to allow 2.7, then the PHP 5.5 testsuite has only five fails, all in gd. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
On Tue, Mar 26, 2013 at 4:43 AM, Christopher Jones christopher.jo...@oracle.com wrote: On 03/25/2013 08:41 AM, Remi Collet wrote: Le 25/03/2013 06:47, Laruence a écrit : attached here: https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build_2.patchrevision=latest Tested under RHEL 6.4 (bison 2.4.1), Fedora 17 (bison 2.5) and Fedora 18 (bison 2.6.1). NTS and ZTS build OK. Thanks, Remi. Bison 2.3 with Oracle Linux 5.9 (and therefore with RHEL 5.9) gives this error: /home/cjones/php-5.5/Zend/zend_language_parser.y:50.1-5: invalid directive: `%code' /home/cjones/php-5.5/Zend/zend_language_parser.y:50.7-14: syntax error, unexpected identifier Hey, it's weird, I have tested with bison 2.3 (cents), it works fine.. version: bison (GNU Bison) 2.3 thanks [You can get Oracle Linux (and keep up to date with patches and security errata) from http://public-yum.oracle.com/] Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
