[PHP-DEV] Proposal for serious BC compatibility aka language versioning
Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hi, On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. We have been there, no chance to go back again with such tags. Also the new release process RFC (https://wiki.php.net/rfc/releaseprocess) solves the BC issues between minor updates (5.4 to 5.5, or 5.3 to 5.4 f.e.). It is our and our users role to explain that to their ISPs, admins, etc. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: jenkins
this account will be used to keep the ci.qa.php.net jenkins installation\#039;s config file in sync with the web/jenkins git repo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: jenkins
On Sun, Feb 3, 2013 at 1:30 PM, jenkins jenk...@ci.qa.php.net wrote: this account will be used to keep the ci.qa.php.net jenkins installation\#039;s config file in sync with the web/jenkins git repo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, I requested this one, please approve it and also grant him karma for web/jenkins.git -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] VCS Account Request: jenkins
hi, On Sun, Feb 3, 2013 at 1:33 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Feb 3, 2013 at 1:30 PM, jenkins jenk...@ci.qa.php.net wrote: this account will be used to keep the ci.qa.php.net jenkins installation\#039;s config file in sync with the web/jenkins git repo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, I requested this one, please approve it and also grant him karma for web/jenkins.git I really do not think that we should give write access to some web exposed bot to any of your repositories. We never allowed that in the past and I do not think we should begin to do that. For what I understand from Ferenc's explanation on IRC, it is about being to store the configuration changed done via the web frontend in git. As the idea itself is good (having that in the repo is good), I would rather go the other way round, modify the configuration in the repo by human being. Configurations can be exported or fetched relatively easily. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: jenkins
On Sun, Feb 3, 2013 at 2:10 PM, Pierre Joye pierre@gmail.com wrote: hi, On Sun, Feb 3, 2013 at 1:33 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Feb 3, 2013 at 1:30 PM, jenkins jenk...@ci.qa.php.net wrote: this account will be used to keep the ci.qa.php.net jenkins installation\#039;s config file in sync with the web/jenkins git repo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, I requested this one, please approve it and also grant him karma for web/jenkins.git I really do not think that we should give write access to some web exposed bot to any of your repositories. We never allowed that in the past and I do not think we should begin to do that. For what I understand from Ferenc's explanation on IRC, it is about being to store the configuration changed done via the web frontend in git. As the idea itself is good (having that in the repo is good), I would rather go the other way round, modify the configuration in the repo by human being. Configurations can be exported or fetched relatively easily. Cheers, -- Pierre @pierrejoye Hi, 99% of the changes to the jenkins configuration files (/config.xml, /job/*/config.xml) will be done through the admin interface, and I don't think that anybody here would be able to edit these files manually without tripping over something. So the other was around solution would require either 1, to have a development environment, where you do the changes, then fetch the changes in the xml files, then commit and push those changes, then log in to the jenkins admin and pull the changes (then restart jenkins if required). or 2, to change it on the jenkins admin, then fetch the changes in the xml files(this would require having ssh account there), then commit push. I think that 1, is would be too cumbersome to be used and 2, would require giving out ssh accounts and would prone people not fetching and pushing the changes when they do change something. The plugin that I wanted to use ( https://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin) would allow the changes to be pushed/pulled from the jenkins allow interface and would also show the current status (changes not pushed, etc.) so it is less likely to we forget to do it. Personally I'm not convinced about the security implications (as this is a separate repository and nothing else would use this repo for anything else), but if you think this is a major concern, I can use my personal github account for storing the configs for the time being. I just thought that it would be better to keep them on git.php.net, thats all. ps: some background info: some of the config files were lost when the previous ci.qa.php.net went down and I want to prevent that from happening ever again. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] (non)growing memory while creating anoymous functions via eval()
Hi all
In this example (using php-5.4.11 on Linux) the memory will grow non-stop:
for ( $fp = fopen('/dev/urandom', 'rb'); true;) {
eval ('$ano_fnc = function() {$x = '.bin2hex(fread($fp, mt_rand(1,
1))).';};');
echo Mem usage: .memory_get_usage().\n;
}
But in this example not:
for ( $fp = fopen('/dev/urandom', 'rb'); true;) {
eval ('$ano_fnc = function() {$x = '.bin2hex(fread($fp,
1)).';};');
echo Mem usage: .memory_get_usage().\n;
}
The only different in the second example is the fixed body length of the
eval()-created anoymous function.
I wondering why the memory in the second code-example will be freed at
some point while in the first example not.
I don't think it's a PHP-Bug but i also not understand this behavior.
Is there one who can explain this?
Thank you very much.
Greetings
Hans-Juergen Petrich
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
On 03/02/13 16:27, Hans-Juergen Petrich wrote:
The only different in the second example is the fixed body length of
the eval()-created anoymous function.
I wondering why the memory in the second code-example will be freed at
some point while in the first example not.
I don't think it's a PHP-Bug but i also not understand this behavior.
Is there one who can explain this?
Thank you very much.
Greetings
Hans-Juergen Petrich
It can be simplified to:
?php
while (true) {
$value = mt_rand(1, 1);
$a = '$ano_fnc = function() {' . str_repeat( , $value) . '};';
eval ($a);
echo Mem usage: .memory_get_usage().\n;
}
The function *is* being removed, $ano_fnc alternates between
object(Closure)#1 and object(Closure)#2, it's not leaking function objects.
I suspect eval is checking a hashtable which is being forced to resize
continuously, but it shouldn't grow unbounded either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
Am 03.02.2013 16:27, schrieb Hans-Juergen Petrich: Is there one who can explain this? Can you explain why you are using eval() instead of a real anonymous function? Thanks! -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
Am 03.02.2013 18:07, schrieb Sebastian Bergmann: Can you explain why you are using eval() instead of a real anonymous function? Thanks! Please ignore my email; I mixed up create_function() and eval(). Then again, your code still does not make sense to me ... -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FILTER_VALIDATE_INT and +0/-0
Back in December I submitted a pull request to make FILTER_VALIDATE_INT accept +0/-0. That request was merged into php-src: https://github.com/php/php-src/pull/248 The other day I then stumbled upon a note on http://www.php.net/manual/en/filter.filters.validate.php saying Numbers +0 and -0 are not valid integers but validate as floats., which makes me wonder if the previous behavior (rejecting +0/-0) was on purpose rather than by mistake? Or should the documentation be adjusted to reflect the new behavior? - Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
2013/2/3 Sebastian Bergmann sebast...@php.net
Am 03.02.2013 18:07, schrieb Sebastian Bergmann:
Can you explain why you are using eval() instead of a real anonymous
function? Thanks!
Please ignore my email; I mixed up create_function() and eval(). Then
again, your code still does not make sense to me ...
Don't know, how create_function() works internally, but it seems, that they
at least act quite similar
?php
create_function('','}echo Foo;{'); // Foo
http://codepad.viper-7.com/h6NQfO
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] FILTER_VALIDATE_INT and +0/-0
On Sun, Feb 3, 2013 at 1:15 PM, Martin Jansen mar...@divbyzero.net wrote: Back in December I submitted a pull request to make FILTER_VALIDATE_INT accept +0/-0. That request was merged into php-src: https://github.com/php/php-src/pull/248 The other day I then stumbled upon a note on http://www.php.net/manual/en/filter.filters.validate.php saying Numbers +0 and -0 are not valid integers but validate as floats., which makes me wonder if the previous behavior (rejecting +0/-0) was on purpose rather than by mistake? Or should the documentation be adjusted to reflect the new behavior? - Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Well, as far as I can tell that note was there back when FILTER_VALIDATE_INT didn't accept +/-0 as a valid int. I'll go ahead and update the docs to note the change in behavior.
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. If you want I can dig around in our issue queue for more backwards compatibility breaks but there are some. Regards, Karoly Negyesi On Sun, Feb 3, 2013 at 4:19 AM, Pierre Joye pierre@gmail.com wrote: hi, On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. We have been there, no chance to go back again with such tags. Also the new release process RFC (https://wiki.php.net/rfc/releaseprocess) solves the BC issues between minor updates (5.4 to 5.5, or 5.3 to 5.4 f.e.). It is our and our users role to explain that to their ISPs, admins, etc. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 11:44 AM, Karoly Negyesi wrote: Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. We do not consider a change in warnings/notices a BC break. I realize for certain test frameworks and custom error handlers it could break things if they are expecting a specific warning or lack of warning, but the code itself behaves exactly as it did before and as such there is no BC break. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 8:44 PM, Karoly Negyesi kar...@negyesi.net wrote: Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. If you want I can dig around in our issue queue for more backwards compatibility breaks but there are some. Regards, Karoly Negyesi As Rasmus mentioned before our current release policy allows warnings/etc. to be added in a minor release. If this is the same test that you mentioned before on irc, then one could argue that this change was useful as it helped you spot and error in you testsuite (comparing a multi-dimensional array using array_diff_assoc which not comparing the arrays but the string Array. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 2:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/03/2013 11:44 AM, Karoly Negyesi wrote: Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. We do not consider a change in warnings/notices a BC break. I realize for certain test frameworks and custom error handlers it could break things if they are expecting a specific warning or lack of warning, but the code itself behaves exactly as it did before and as such there is no BC break. I for one think this point needs to be communicated a lot more clearly, because when I attempted to introduce a patch that would throw E_DEPRECATED warning for mcrypt last year I was told it could not be merged in 5.4 since it would cause a BC break. Later someone else disagreed with that. So clearly not everyone seems to be inline. /my two cents -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Best, Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 01:48 PM, Karoly Negyesi wrote: We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Well, that is obviously not realistic. Every change we make has some level of BC impact. We have to draw a line somewhere. Heck, even fixing a segfault is technically a BC change because the behaviour from one version to the next is different. A 100% strict no BC rule would mean we couldn't actually ever fix any bugs. There has to be a line. Our line is that in minor version upgrades we won't change documented functional behaviour unless there are extremely serious (usually security-related) reasons for doing so. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Well, fixing a segfault, adding a new function or method as it oft happened in PHP 5.3 is only breaking forwards compatibility not backwards -- if you have code that ran on PHP 5.3.4 it'll run on 5.3.5. The reverse is not true which causes some headaches to Drupal developers but it's not relevant to this discussion. So, what about adding a version string to the opening ?php tag so that you can fix bugs while not breaking BC :P ? On Sun, Feb 3, 2013 at 1:55 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/03/2013 01:48 PM, Karoly Negyesi wrote: We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Well, that is obviously not realistic. Every change we make has some level of BC impact. We have to draw a line somewhere. Heck, even fixing a segfault is technically a BC change because the behaviour from one version to the next is different. A 100% strict no BC rule would mean we couldn't actually ever fix any bugs. There has to be a line. Our line is that in minor version upgrades we won't change documented functional behaviour unless there are extremely serious (usually security-related) reasons for doing so. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:03 PM, Karoly Negyesi wrote: Well, fixing a segfault, adding a new function or method as it oft happened in PHP 5.3 is only breaking forwards compatibility not backwards -- if you have code that ran on PHP 5.3.4 it'll run on 5.3.5. The reverse is not true which causes some headaches to Drupal developers but it's not relevant to this discussion. So, what about adding a version string to the opening ?php tag so that you can fix bugs while not breaking BC :P ? We had that in the past and it was a mess. We are not going to make that mistake again. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
If you mean ?php3 then well, I was not here but maybe we could learn from the mistakes and get a better implementation? I have some ideas, but first I'd be glad to learn why it was a mess. On Sun, Feb 3, 2013 at 2:06 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/03/2013 02:03 PM, Karoly Negyesi wrote: Well, fixing a segfault, adding a new function or method as it oft happened in PHP 5.3 is only breaking forwards compatibility not backwards -- if you have code that ran on PHP 5.3.4 it'll run on 5.3.5. The reverse is not true which causes some headaches to Drupal developers but it's not relevant to this discussion. So, what about adding a version string to the opening ?php tag so that you can fix bugs while not breaking BC :P ? We had that in the past and it was a mess. We are not going to make that mistake again. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Agreed with the others that this should not go into the engine (and this should also not really clutter up the Internals list), but if you have a real need for running different versions of PHP for different URLs, you could pretty easily set up multiple FPM backends (one for each version you support) and have Nginx map URLs to these. It would be a maintenance headache, but not the disaster this would be if it had to be maintained in PHP-proper. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:11 PM, Karoly Negyesi wrote: If you mean ?php3 then well, I was not here but maybe we could learn from the mistakes and get a better implementation? I have some ideas, but first I'd be glad to learn why it was a mess. The whole concept of maintaining multiple personalities in the same codebase is a complete non-starter. The complexity that leads to is mindnumbing. There really isn't anything to discuss along these lines. It will not happen. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Hm, there is a slight miscommunication which is my fault. I do not suggest a PHP engine being compatible with 5 and 6, gosh, no. I suggest a PHP engine compatible with 5.3 and 5.4. Is that a maintenance mess too? The difference should be a lot, lot smaller. And yes, interaction is a problem and again I'd be glad to discuss on how to behave for those. Regards NK On Sun, Feb 3, 2013 at 2:22 PM, Nikita Popov nikita@gmail.com wrote: On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:27 PM, Karoly Negyesi wrote: Hm, there is a slight miscommunication which is my fault. I do not suggest a PHP engine being compatible with 5 and 6, gosh, no. I suggest a PHP engine compatible with 5.3 and 5.4. Is that a maintenance mess too? The difference should be a lot, lot smaller. And yes, interaction is a problem and again I'd be glad to discuss on how to behave for those. It doesn't matter which versions you are talking about. Any sort of multiple-personality support would turn into a complete maintenance nightmare. We try to move things along at a responsible pace in the direction that we want things to go. Sometimes that involves some pain. And yes, sometimes we don't always realize that there is code out there relying certain things. Like the fact that Drupal relied on array_diff_asccoc() comparing array(1,2,3) to Array and saying those were equivalent without any sort of notice. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FILTER_VALIDATE_INT and +0/-0
On Sun, 3 Feb 2013, Martin Jansen wrote: Back in December I submitted a pull request to make FILTER_VALIDATE_INT accept +0/-0. That request was merged into php-src: https://github.com/php/php-src/pull/248 The other day I then stumbled upon a note on http://www.php.net/manual/en/filter.filters.validate.php saying Numbers +0 and -0 are not valid integers but validate as floats., which makes me wonder if the previous behavior (rejecting +0/-0) was on purpose rather than by mistake? +0 and -0 don't make sense for integers, where there is only 0. Allowing only 0 was on purpose. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
array_diff_asccoc() comparing array(1,2,3) to Array and saying those were equivalent without any sort of notice. That's not what happened, some contib was comparing array(1,2,3) to array(1,2,array(3)) and even looking at the documentation it is not clear whether the cast should or should not throw a notice. But, if that's desired behavior, I will add a note to warn people. Best Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:39 PM, Karoly Negyesi wrote: array_diff_asccoc() comparing array(1,2,3) to Array and saying those were equivalent without any sort of notice. That's not what happened, some contib was comparing array(1,2,3) to array(1,2,array(3)) and even looking at the documentation it is not clear whether the cast should or should not throw a notice. But, if that's desired behavior, I will add a note to warn people. The cast should always throw a notice. The function is documented to only compare single-dimensional arrays, so if you pass it a multi-dimensional array it is going to treat them as a single dimensional and the only way to do that is to cast them to scalars. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 11:22 PM, Nikita Popov nikita@gmail.com wrote: On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita Just run two different PHP versions. Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. Regards, Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:49 PM, Thomas Bley wrote: On Sun, Feb 3, 2013 at 11:22 PM, Nikita Popov nikita@gmail.com wrote: On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita Just run two different PHP versions. Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. Nothing stops you from doing that. Compile as many versions as you want with different --with-config-file-path settings. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 03.02.2013 23:49, Thomas Bley wrote: Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. I don't think you'd find many people here disagreeing with distribution maintainers providing packages for multiple version at the same time (like 5.3 and 5.4) - so that suggestion should be brought to these people. (I know, some are reading this list.) I've never seen anyone on this list telling a distribution maintainer not to use /etc/php5.3 or something, please enlighten me if that's not the case. Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 1:48 PM, Karoly Negyesi kar...@negyesi.net wrote: We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Best, Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As Rasmus already pointed out, 100% backwards compatibility is simply unrealistic. You would also be hard-pressed to find any scripting language out there that puts as much focus on maintaining BC as PHP does. Personally, I think we worry about it a little too much when it comes to major version changes. If you write your code to be scalable and have at least some sliver of forward compatibility, then minor changes like notices and warnings should not cause your codebase to blow up in your face. If they are causing that and fixing it would require a lot of support tickets, as you put it, then I think the problem is with your code, not PHP. You should always anticipate possible changes in the language when writing your code if you plan on upgrading to the latest versions of the language. There is a simple solution for maintaining 100% BC: Don't upgrade PHP. Same goes for Perl, Python, Java, etc. If your code isn't forward compatible, just target it to the version it was written for and you're good to go. If you want people to be able to upgrade PHP, then you have to do your part by making your code scalable at least to a reasonable degree. I think we already do more than our part with how careful we are about behavioral changes in minor version increments. I also agree that different tags for different versions is just impractical and represents a maintenance nightmare. But if you really want to go forward with your suggestion, write an RFC to be voted on. I'd be happy to publish it to the wiki on your behalf, though I won't be voting for it. --Kris
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 11:56 PM, Florian Anderiasch m...@anderiasch.de wrote: On 03.02.2013 23:49, Thomas Bley wrote: Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. I don't think you'd find many people here disagreeing with distribution maintainers providing packages for multiple version at the same time (like 5.3 and 5.4) - so that suggestion should be brought to these people. (I know, some are reading this list.) I've never seen anyone on this list telling a distribution maintainer not to use /etc/php5.3 or something, please enlighten me if that's not the case. Greetings, Florian If I see it correctly, none of Debian, Ubuntu, openSUSE, CentOS, Fedora currently offer more than one version of PHP. The majority of the stable/lts distributions is currently on 5.3.x. Getting packages for different versions and the ability to run them in parallel might also give a push in testing alphas. Regards, Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
Hi Terry and all thank you very much for your response. The only thing that confused me about what you say that the second *doesn't* grow Yes, about that i was [and am still :-)] also confused... why the 2nd one won't grow *non-stop* so I checked and it does -- just the same as the first. Right, it grows, but not non-stop as in the 1st one. The memory will stop growing (on my machine) at ~2491584 bytes and the loop is able to run forever, creating each eval() furthermore uniqe ano-function's but not endless-filling Zend-internal tables. but this still leaves the function record itself in the function_table hash so with a non-zero reference count and this doesn't get DTORed until request shutdown Not familar with the Zend-internals but just about so i was imaging and expecting it. That why i [still] also confused/wondering why in the 2nd example the memory will not grow *endless*. It seems that the function records in the function_table will be DTORed (or similar cleaned up) before request-shutdown at some point... Could this be the case? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Questioning the future of PHP
Hello all. I'd like to start by saying that I am by no means an expert on the subject at hand, and my knowledge is limited to pretty much basic C/C++. I have done little more than patch and write ad hoc extensions for PHP in the past. I'm not looking to criticize so much, as I'm just interested in an honest discussion, for my own sake and understanding. Many years ago I was on this internals list lamenting that PHP lacked namespaces. I was passionate in my conviction that it couldn't be a true language if it lacked them. But it wasn't until they were finally being considered that I realized the one weakness in PHP that prevented a proper namespace system. The autoload problem. Since PHP lacks an inherent style of code importation, it is a decision largely left up to the developer. This of course causes an order of precedence problem. Now, I won't lie, some of my beef with namespaces as they stand is the \. What can I say, I like a certain feng shui in my code. I understand the technical limitations (or at least think I do) and the problem of ambiguity with other operators, however I feel more effort might have been made. If I were to pull some examples out of my ass, and feel free to rebuke me if I'm missing something obvious, [namespace foo.bar] new [foo.bar.SomeClass]() Would that be so hard to distinguish in the parser? If it is, I'd be grateful to know why. Touching back on what I mentioned earlier about PHP not having an inherent way to load files, and in daily use it's somewhat arbitrary. I share the philosophy that the programmer should tell the code what to do, and not the other way around; however, I think some enforced structure can be good. This is something of a wet dream of mine and one I highly doubt will come true, but to get rid of __autoload (or at least supplant it with a default loader) would be a dream. I think it's something that PHP needs, to complete some one of advances its made in recent years. Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (non)growing memory while creating anoymous functions via eval()
Hello
Then again, your code still does not make sense to me ...
Fully understand :-)
Not want wasting your time with my specific situation... but there are
situation where it make sense :-)
For example... in my situation, i have time intensive (mathematically)
operations to do in pure php
and was searching a way to speed this operations up.
With PHP's eval() feature, creating php code at run time, this would be,
in my situation, a possible way.
Very simplified, i have to deal with the following:
function calculate($ints)
{
$result = 0;
for ($i=0; $i1000; ++$i) {
$result += $ints[0] + $ints[1] + $ints[2] + $ints[3] + $ints[4] +
$ints[5];
}
return $result;
}
$ints = array(1,2,3,4,5,6);
$result = calculate($ints);
A faster way would be:
$ints = array(1,2,3,4,5,6);
eval('$calculate = function () {
$result = 0;
for ($i=0; $i1000; ++$i) {
$result += '.$ints[0].' + '.$ints[1].' + '.$ints[2].' + '.$ints[3].' +
'.$ints[4].' + '.$ints[5].';
}
return $result;
};');
$result = $calculate();
The function code it self is in reality more complex and variable in the
function-body length, but the princip is the same.
The code-architecture, in my specific situation, requires also that the
operation encapsulated in a function.
(And for security: It is ensured that $int is an 1-dim array filled only
with integers)
$calculate() works very fine and, of course, much faster than the
hardcoded calculate().
Each time $ints is changing i also have, of course, re-define/creater
$calculate() via eval.
In such situations, for performance reasons, it would makes sense using
eval() for re/creating ano-functions, doesn't it?
And as long as the function-body has a fixed length each time re/creating
the ano-function via eval() it would also not let grow the memory endless.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questioning the future of PHP
This is something of a wet dream of mine TMI, my friend. TMI. Anyway... I think your Subject is unnecessarily trolly even if the substance of your post isn't. So maybe you could re-post with a WAS: Questioning... to avoid p'ing off the dev team? If I'm understanding your statement of The autoload problem correctly, the language-default spl_autoload function indeed allows you to install a package safely -- in an environment that you know has not completely overridden the default autoloader. If you want to make sure the default is called for your directory structure, then you can make sure to tell the people using your package to put the default spl_autoload in their autoloader chain. Can you explain how this departs from your vision? I don't think what you want is another default autoloader, but a way of ensuring the system default is called once your package is physically installed on a system. Unfortunately, there would always be file I/O overhead if it were to be called even if the PHP install has nothing in the default file layout. You could argue that the default spl_autoload should run unless deliberately turned off (never mind BC for the moment), but then it would just become a popular best practice to turn it off and you're back at the same place. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questioning the future of PHP
On 02/03/2013 08:51 PM, Matt Wilson wrote: Hello all. I'd like to start by saying that I am by no means an expert on the subject at hand, and my knowledge is limited to pretty much basic C/C++. I have done little more than patch and write ad hoc extensions for PHP in the past. I'm not looking to criticize so much, as I'm just interested in an honest discussion, for my own sake and understanding. Many years ago I was on this internals list lamenting that PHP lacked namespaces. I was passionate in my conviction that it couldn't be a true language if it lacked them. But it wasn't until they were finally being considered that I realized the one weakness in PHP that prevented a proper namespace system. The autoload problem. Since PHP lacks an inherent style of code importation, it is a decision largely left up to the developer. This of course causes an order of precedence problem. Now, I won't lie, some of my beef with namespaces as they stand is the \. What can I say, I like a certain feng shui in my code. I understand the technical limitations (or at least think I do) and the problem of ambiguity with other operators, however I feel more effort might have been made. If I were to pull some examples out of my ass, and feel free to rebuke me if I'm missing something obvious, [namespace foo.bar] new [foo.bar.SomeClass]() Would that be so hard to distinguish in the parser? If it is, I'd be grateful to know why. Maybe it would work, maybe it wouldn't, I don't know. But that ship sailed a long time ago and it cannot be changed now without breaking a few million lines of code. Please let that issue die. Touching back on what I mentioned earlier about PHP not having an inherent way to load files, and in daily use it's somewhat arbitrary. I share the philosophy that the programmer should tell the code what to do, and not the other way around; however, I think some enforced structure can be good. This is something of a wet dream of mine and one I highly doubt will come true, but to get rid of __autoload (or at least supplant it with a default loader) would be a dream. I think it's something that PHP needs, to complete some one of advances its made in recent years. Thanks, Matt The autoload problem has already been solved by PSR-0. If you're not using it yet, you should. All the cool kids are. http://www.php-fig.org/ If you're using Composer to manage dependencies, it includes a fully capable PSR-0 autoloader that just works, as well as a classmap-based option. If you're not using it yet, you should. All the cool kids are. http://getcomposer.org/ --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/13 23:56, Florian Anderiasch wrote: On 03.02.2013 23:49, Thomas Bley wrote: Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. I don't think you'd find many people here disagreeing with distribution maintainers providing packages for multiple version at the same time (like 5.3 and 5.4) - so that suggestion should be brought to these people. (I know, some are reading this list.) I've never seen anyone on this list telling a distribution maintainer not to use /etc/php5.3 or something, please enlighten me if that's not the case. Gentoo has allowed its users to install multiple versions of PHP for a few years now, and also running multiple versions of php-fpm in parallel. So far it has not been that much of a problem to maintain, seemingly much easier than offering the same for ruby or python. - -- Ole Markus -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJRD1o8AAoJEGurSuXEqSv12rgH/j39u30ONtvZnarsuC9A6Pjp j/xjVTUrIIeNNKAjXQPxc8XgfJ9QBOTZxaZ6ZtocUMe4sLrwukal2o/njM7kmhSc VYpbhNYDbExX0Rq/7qMQn8fUialoOb45sv2RsCmCk6Abx4NRWPmLYMGU/FLUYwcS TBKHevQ6VsYDu/G85W26iyA3jpk8RTRk42mwrAtIePl0gNcpmbVHrNXhjhHF5tbB RRm5lHvpM2BO38xSh+wAqk+sqNuTTwj3elOGKhMbwICEzHIaIiaqq+Gu4jVwsAke Zz8R4qtfMXE4hDwIezIukAgye2GpK5WRe3wG9czMyO+xrv5Y+KkP3lRwobkxbeo= =2+mI -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Thomas Bley in php.internals (Mon, 4 Feb 2013 02:06:02 +0100): If I see it correctly, none of Debian, Ubuntu, openSUSE, CentOS, Fedora currently offer more than one version of PHP. Directadmin does, I am using it on CentOS. http://forum.directadmin.com/showthread.php?t=44743 Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questioning the future of PHP
We still don't have a way to auto load non class entities. Other than that, PSR-0 does solve the majority of autoload use cases. Cheers, David Sent from my iPhone On 04/02/2013, at 5:18 PM, Larry Garfield la...@garfieldtech.com wrote: On 02/03/2013 08:51 PM, Matt Wilson wrote: Hello all. I'd like to start by saying that I am by no means an expert on the subject at hand, and my knowledge is limited to pretty much basic C/C++. I have done little more than patch and write ad hoc extensions for PHP in the past. I'm not looking to criticize so much, as I'm just interested in an honest discussion, for my own sake and understanding. Many years ago I was on this internals list lamenting that PHP lacked namespaces. I was passionate in my conviction that it couldn't be a true language if it lacked them. But it wasn't until they were finally being considered that I realized the one weakness in PHP that prevented a proper namespace system. The autoload problem. Since PHP lacks an inherent style of code importation, it is a decision largely left up to the developer. This of course causes an order of precedence problem. Now, I won't lie, some of my beef with namespaces as they stand is the \. What can I say, I like a certain feng shui in my code. I understand the technical limitations (or at least think I do) and the problem of ambiguity with other operators, however I feel more effort might have been made. If I were to pull some examples out of my ass, and feel free to rebuke me if I'm missing something obvious, [namespace foo.bar] new [foo.bar.SomeClass]() Would that be so hard to distinguish in the parser? If it is, I'd be grateful to know why. Maybe it would work, maybe it wouldn't, I don't know. But that ship sailed a long time ago and it cannot be changed now without breaking a few million lines of code. Please let that issue die. Touching back on what I mentioned earlier about PHP not having an inherent way to load files, and in daily use it's somewhat arbitrary. I share the philosophy that the programmer should tell the code what to do, and not the other way around; however, I think some enforced structure can be good. This is something of a wet dream of mine and one I highly doubt will come true, but to get rid of __autoload (or at least supplant it with a default loader) would be a dream. I think it's something that PHP needs, to complete some one of advances its made in recent years. Thanks, Matt The autoload problem has already been solved by PSR-0. If you're not using it yet, you should. All the cool kids are. http://www.php-fig.org/ If you're using Composer to manage dependencies, it includes a fully capable PSR-0 autoloader that just works, as well as a classmap-based option. If you're not using it yet, you should. All the cool kids are. http://getcomposer.org/ --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update PHP stats?
Hi, On 4 February 2013 07:41, Martin Keckeis martin.kecke...@gmail.com wrote: Hello, netcraft got new numbers. Maybe the outdated usage page could get updated? http://www.php.net/usage.php http://news.netcraft.com/archives/2013/01/31/php-just-grows-grows.html I have been in touch with Netcraft about updating this page, and keeping it more up-to-date in the future. Cheers, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
