Re: [PHP-DEV] libc and random functions
On 7/19/07, Pierre <[EMAIL PROTECTED]> wrote: On 7/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I totally agree. the only reasn for the 5-2 patch was for people to test You can simply keep the old functions for 5.2 and remove them in HEAD. We can't remove an API (or change it) in a point release, it is a full breakage (BC and binary). --Pierre I agree, this was mainly for HEAD, but just wanted to give an opportunity to people to test it. HEAD it is :) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
On 7/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I totally agree. the only reasn for the 5-2 patch was for people to test You can simply keep the old functions for 5.2 and remove them in HEAD. We can't remove an API (or change it) in a point release, it is a full breakage (BC and binary). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
I totally agree. the only reasn for the 5-2 patch was for people to test On 7/19/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote: Hi David, On Thu, 2007-07-19 at 13:09 -0400, David Coallier wrote: > After a bit of discussion with Jani, I came to realize that keeping > the wrapper macro for php_rand, php_srand is plain useless. Yes some > pecl extensions do rely on them (and for those who do, I also provided > a patch [3]). We both realized that there's not many extensions > relying on php_rand and php_srand thus removed it completely.. I don't think that removing APIs during a point release is a good thing. Even when you grepped through PECL it doesn't mean that not more extensions are using these functions. I'm fine with removing it from HEAD, if there's an replacement but not for a bugfix release. johannes -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
Hi David, On Thu, 2007-07-19 at 13:09 -0400, David Coallier wrote: > After a bit of discussion with Jani, I came to realize that keeping > the wrapper macro for php_rand, php_srand is plain useless. Yes some > pecl extensions do rely on them (and for those who do, I also provided > a patch [3]). We both realized that there's not many extensions > relying on php_rand and php_srand thus removed it completely.. I don't think that removing APIs during a point release is a good thing. Even when you grepped through PECL it doesn't mean that not more extensions are using these functions. I'm fine with removing it from HEAD, if there's an replacement but not for a bugfix release. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
On 7/19/07, David Coallier <[EMAIL PROTECTED]> wrote: On 7/19/07, Antony Dovgal <[EMAIL PROTECTED]> wrote: > On 19.07.2007 17:41, Keryx Web wrote: > > Ilia Alshanetsky wrote: > >> Do you have a patch? > > > > Also @Antony Dovgal in the "let blocks" thread > > > > Short answer: No. > > > > The reason I posted my suggestions on this list was that a while ago I > > had a few ideas as to how PHP could be improved. > > What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way? > > If there are no problems, then please don't improve anything not broken. > "No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine. > Sorry I did not quite answer your question in my email + patch. Yes it works correctly as it is, however, with this patch, the random numbers being generated are using an algorithm (Mersenne Twister) that allows us to give more randomness if I may use the term. So it simply doesn't *fix* anything, but improves random number generation. There are various reasons why people are using random generated numbers and mt_ is more random than rand*. Simply it. It does not **fix** something that is broken, simply improves it. Yes we could still use a rock to make fire, and it still works fine, but might as well use matches, lenses or lighters. It's more effective and faster. > -- > Wbr, > Antony Dovgal > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Here are three patches against HEAD [1], 5_2 [2] and the pecl repository [3] (Do not shout just yet, I'll explain). The idea of the patches are pretty simple, aliasing rand, srand, getrandmax to mt_rand, mt_srand, and mt_getrandmax. The goal is simply having a better number generation. Nothing fancier, or more different, but simply it. It works great (compiling great against 5_2, HEAD) and Crisitan Rodriguez also tried the compilation. After a bit of discussion with Jani, I came to realize that keeping the wrapper macro for php_rand, php_srand is plain useless. Yes some pecl extensions do rely on them (and for those who do, I also provided a patch [3]). We both realized that there's not many extensions relying on php_rand and php_srand thus removed it completely.. Here are the patches: [1] HEAD : http://dev.agoraproduction.com/php/php6/head-mt-changes.diff [2] 5_2 : http://dev.agoraproduction.com/php/5_2/5.2-mt-changes.diff [3] PECL : http://dev.agoraproduction.com/php/php6/pecl-mt-changes.diff Please note that the mt-changes patches are not only changing ext/standard/* but also the ext/* relying on them. (soap, mcrypt) but also a small change in main/reentrancy.c both in 5_2 and HEAD. Thanks, -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
On 7/19/07, Antony Dovgal <[EMAIL PROTECTED]> wrote: On 19.07.2007 17:41, Keryx Web wrote: > Ilia Alshanetsky wrote: >> Do you have a patch? > > Also @Antony Dovgal in the "let blocks" thread > > Short answer: No. > > The reason I posted my suggestions on this list was that a while ago I > had a few ideas as to how PHP could be improved. What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way? If there are no problems, then please don't improve anything not broken. "No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Here are three patches against HEAD [1], 5_2 [2] and the pecl repository [3] (Do not shout just yet, I'll explain). The idea of the patches are pretty simple, aliasing rand, srand, getrandmax to mt_rand, mt_srand, and mt_getrandmax. The goal is simply having a better number generation. Nothing fancier, or more different, but simply it. It works great (compiling great against 5_2, HEAD) and Crisitan Rodriguez also tried the compilation. After a bit of discussion with Jani, I came to realize that keeping the wrapper macro for php_rand, php_srand is plain useless. Yes some pecl extensions do rely on them (and for those who do, I also provided a patch [3]). We both realized that there's not many extensions relying on php_rand and php_srand thus removed it completely.. Here are the patches: [1] HEAD : http://dev.agoraproduction.com/php/php6/head-mt-changes.diff [2] 5_2 : http://dev.agoraproduction.com/php/5_2/5.2-mt-changes.diff [3] PECL : http://dev.agoraproduction.com/php/php6/pecl-mt-changes.diff Please note that the mt-changes patches are not only changing ext/standard/* but also the ext/* relying on them. (soap, mcrypt) but also a small change in main/reentrancy.c both in 5_2 and HEAD. Thanks, -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
On 19.07.2007 17:41, Keryx Web wrote: Ilia Alshanetsky wrote: Do you have a patch? Also @Antony Dovgal in the "let blocks" thread Short answer: No. The reason I posted my suggestions on this list was that a while ago I had a few ideas as to how PHP could be improved. What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way? If there are no problems, then please don't improve anything not broken. "No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
On 7/19/07, Keryx Web <[EMAIL PROTECTED]> wrote: Ilia Alshanetsky wrote: > Do you have a patch? Also @Antony Dovgal in the "let blocks" thread Short answer: No. The reason I posted my suggestions on this list was that a while ago I had a few ideas as to how PHP could be improved. A seasoned PHP developer suggested that I'd take my suggestions to this list. As I have no "commit karma" - as it has been dubbed elsewhere - I have tried to be polite and keep a low profile, only speaking out when I thought that my perspective could be of value to the discussion at hand. Now I have two questions: (1) Is it considered bad form to make feature suggestions on this list, even though I am not in the position to make any patches myself? (2) If so, can anyone point me to the place where such a feature request might be made? And now - hypothetically speaking - maybe I could find some time during this autumn to actually learn a bit more C and make a patch. Wouldn't it be better if I made a patch that the community thought worthwhile and not spend my time developing something none ever would commit? Just having someone say: "That sounds like a good idea", would be an encouragement for such an undertaking. Lars Gunther -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Side note for you Lars, I have a patch for the initial request on this thread about rand -> mt_rand, etc. I'm just making sure i'm not breaking any extensions, and then I'll send it on the list :) Should be in about an hour or so. -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
Ilia Alshanetsky wrote: Do you have a patch? Also @Antony Dovgal in the "let blocks" thread Short answer: No. The reason I posted my suggestions on this list was that a while ago I had a few ideas as to how PHP could be improved. A seasoned PHP developer suggested that I'd take my suggestions to this list. As I have no "commit karma" - as it has been dubbed elsewhere - I have tried to be polite and keep a low profile, only speaking out when I thought that my perspective could be of value to the discussion at hand. Now I have two questions: (1) Is it considered bad form to make feature suggestions on this list, even though I am not in the position to make any patches myself? (2) If so, can anyone point me to the place where such a feature request might be made? And now - hypothetically speaking - maybe I could find some time during this autumn to actually learn a bit more C and make a patch. Wouldn't it be better if I made a patch that the community thought worthwhile and not spend my time developing something none ever would commit? Just having someone say: "That sounds like a good idea", would be an encouragement for such an undertaking. Lars Gunther -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libc and random functions
Do you have a patch? On 18-Jul-07, at 2:20 PM, Keryx Web wrote: I do not know if this post made it to the list a while ago. No one answered and i see I used the wrong account to send it. Please forgive me if this is a redundant re-post. This is a suggestion I think would not be too hard to implement: Skip libc for all random functions. As I see it there is no reason to keep it. I can't think of any application that would break if rand() would produce better random results at a higher speed. So basically what I am saying is this: Implement the mersenne twister in the back of all random functions. 1. Make rand() an alias to mt_rand() 2. Make srand() an alias to mt_srand() (And since they are redundant give an E_STRICT?) 3. Make getrandmax() an alias to mt_getrandmax() 4. Have array_rand() implement MT in the back (if it is not doing so already) Lars Gunther P.S. For an introduction to who I am one might read: http://www.webstandards.org/action/edutf/interviews/gunther-en/ and look at http://www.flickr.com/photos/keryxgunther/143376264/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] libc and random functions
I do not know if this post made it to the list a while ago. No one answered and i see I used the wrong account to send it. Please forgive me if this is a redundant re-post. This is a suggestion I think would not be too hard to implement: Skip libc for all random functions. As I see it there is no reason to keep it. I can't think of any application that would break if rand() would produce better random results at a higher speed. So basically what I am saying is this: Implement the mersenne twister in the back of all random functions. 1. Make rand() an alias to mt_rand() 2. Make srand() an alias to mt_srand() (And since they are redundant give an E_STRICT?) 3. Make getrandmax() an alias to mt_getrandmax() 4. Have array_rand() implement MT in the back (if it is not doing so already) Lars Gunther P.S. For an introduction to who I am one might read: http://www.webstandards.org/action/edutf/interviews/gunther-en/ and look at http://www.flickr.com/photos/keryxgunther/143376264/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
