Re: [PHP-DEV] Re: [PEAR-DEV] CVS karma
That's a lot less critical. I ran a sweep a couple of years ago that deleted a couple of hundred old unused accounts. At some point I will run another one, but having unused accounts sitting around really doesn't affect us in any way. -Rasmus Nuno Lopes wrote: And deletion of current cvs accounts? I've run some stats 6 months ago, and about 50% of phpdoc cvs accounts were never used... Nuno - Original Message - I'd love to outsource that part, but we'd need to modify the tools a bit. Anyway, there was a backlog of 39 cvs account requests. I went through them all and approved about a third of them. -Rasmus Alan Knowles wrote: I'm not sure if it's [EMAIL PROTECTED] or [EMAIL PROTECTED] is the best place for this, but internals may help a bit.. unless they want to outsource the karma mgmt of pear stuff to one of the pear group ;) Regards Alan Jesper Veggerby Hansen wrote: Hi guys, Just wondering if anybody has been able to get a new acccount to CVS the last couple of months? Been trying - with what I was told was the official way - through some page hidden deep in the 42nd link from http://php.net/, but hasn't been able to get the right karma, yet. Anybody been successfull or know of which other buttons to press? I think I did take the red pill. Regards Jesper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Major isssue with foreach() in PHP 4.3.10
Found other bug report indicating this is a Zend Optimizer issue. IMHO, an announcement should be made on the homepage indicating if you upgrade to PHP 4.3.10 you should also make sure you upgrade Zend Optimizer. On Thu, 16 Dec 2004 13:53:39 -0600, Jeremy Johnstone [EMAIL PROTECTED] wrote: http://bugs.php.net/bug.php?id=31134 This is breaking a large number of scripts. -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- --- Jeremy Johnstone http://www.jeremyjohnstone.com [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] CVS karma
Well, we have clearly gone away from the cvs account delay problem to some other problem. Which real problem are you trying to solve here? I don't like work just for the sake of work. I see no tangible benefit in doing a lot of work just to reduce the number of idle accounts. -Rasmus Nuno Lopes wrote: And what about a voting system? We would login at master server and vote/comment like in pear/pecl proposals. Nuno - Original Message - Which in itself is not a big deal. And I reject more than I approve actually. For a while I tried to verify each one with the documentation project leads, but half the time they wouldn't respond. I am not sure how other people would do a better job vetting these folks. If they don't contribute anything they will be blown away on the next account cleanup sweep. -Rasmus Nuno Lopes wrote: Are you sure? I know that there are some guys that use their account like a free e-mail account redirection. This is because you 'offer' accounts to everybody that wants to join the doc team. Your idea to out-source karma would be good to handle this problems... (I remember to read a mail in the mirrors ML about this...) Nuno - Original Message - That's a lot less critical. I ran a sweep a couple of years ago that deleted a couple of hundred old unused accounts. At some point I will run another one, but having unused accounts sitting around really doesn't affect us in any way. -Rasmus Nuno Lopes wrote: And deletion of current cvs accounts? I've run some stats 6 months ago, and about 50% of phpdoc cvs accounts were never used... Nuno - Original Message - I'd love to outsource that part, but we'd need to modify the tools a bit. Anyway, there was a backlog of 39 cvs account requests. I went through them all and approved about a third of them. -Rasmus Alan Knowles wrote: I'm not sure if it's [EMAIL PROTECTED] or [EMAIL PROTECTED] is the best place for this, but internals may help a bit.. unless they want to outsource the karma mgmt of pear stuff to one of the pear group ;) Regards Alan Jesper Veggerby Hansen wrote: Hi guys, Just wondering if anybody has been able to get a new acccount to CVS the last couple of months? Been trying - with what I was told was the official way - through some page hidden deep in the 42nd link from http://php.net/, but hasn't been able to get the right karma, yet. Anybody been successfull or know of which other buttons to press? I think I did take the red pill. Regards Jesper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] CVS karma
Hello again, Well, I don't like the voting system either. I agree that it is perhaps too much work for nothing at the end. But what I don't like is the fact that some people might always vote negatively. It's hard around here to prove that you can really help the project (or anything related to PHP). If accounts are not opened based on the fact that I don't know you, I haven't seen any patches from you, we are not helping people wanting to contribute. In PECL/PEAR, you have to prove the idea before the package is added. And sometimes you might have a vague, but good idea, but it will be refused by the fact that not much work has already been done and you should provide enough source code. So yes, the thread has shifted from the original post. And while something /could/ be done to speed up the opening of new CVS accounts, I don't think that the number of accounts should be restricted and checks tightened. This would only reduce the number of persona involved in the project. Sincerely, Olivier Rasmus Lerdorf wrote: Well, we have clearly gone away from the cvs account delay problem to some other problem. Which real problem are you trying to solve here? I don't like work just for the sake of work. I see no tangible benefit in doing a lot of work just to reduce the number of idle accounts. -Rasmus Nuno Lopes wrote: And what about a voting system? We would login at master server and vote/comment like in pear/pecl proposals. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] CVS karma
Rasmus Lerdorf wrote: Correct, you can't go by CVS commits alone. The doc notes group of people never touch CVS but since we don't want to have multiple account management systems we just use the same one. So they all have CVS accounts. Some of them have karma and some of them don't. This is a little old, but: http://livedocs.homelinux.com/ns.htm Reality is that many (not all, as you correctly stated) active notes maintainers do use their accounts. There are also not that many notes maintainers, total. (according to the table marked Total Editors Stats, 183). S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: internals Digest 16 Dec 2004 21:13:03 -0000 Issue 552
, 16/12/2004 21:13 +, [EMAIL PROTECTED] : , 16/12/2004 21:13 +, [EMAIL PROTECTED] : PHP Development Team would like to announce the immediate release of PHP 4.3.10 and 5.0.3. * Improved number handling on non-English locales. What exactly was improved? -- Markus Bertheau [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Major isssue with foreach() in PHP 4.3.10
On Thu, 16 Dec 2004, Jeremy Johnstone wrote: On Thu, 16 Dec 2004 22:00:11 +0100 (CET), Derick Rethans [EMAIL PROTECTED] wrote: And yes, there is another foreach bug of you do: foreach($array as $key = $key) As you mentioned in the bug report, IMHO that isn't a bug. I can't think of any instance where this should be a valid syntax (maybe I am not thinking creatively enough). It's ofcourse totally silly code ;-) Also, this was already in 4.3.1, so no critical thing at all. Atlest it doesn't leak in 4.3.10... So the only bug with foreach was in combination with the Zend Engine AFAIK. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ftp_get_resp ftp_get_conv functions
Hi Jesse, 2500*4096 = 10M on ftpbuf would be too much for the user who is not interested in this functionality. It should be allocating the memory dynamically instead of hardcoding the size to 2500. This need to happen only when requested, may be some option argument to ftp_connect whether to track the ftp conversation. With regards Kamesh Jayachandran On Wed, 15 Dec 2004 21:47:09 -0700, Binam, Jesse [EMAIL PROTECTED] said: The attached diff adds 2 ftp functions. I read the README.SUBMITTING_PATCH and went thru all the steps, but there are no tests for ftp, and I didn't understand how to update the docs. So if someone would like to help me with that, great. Basically, I modifed ftpbuf_t adding a 2 dimensional array (array of strings) to store the conversation, and an int that indicates the next element in first dimension the array. I modified ftp_putcmd and ftp_getresp to add what gets sent/recvd in the conversation. And lastly I added ftp_get_resp which returns the 3 digit return code from the server of the last command sent, and ftp_get_conv (which I would not be opposed to changing the name of, that's just what I came up with) that returns the ftp conversation as an array. Both functions must be called before ftp_close (or ftp_quit) because it frees the resource. The array I defined is 2500x4096. 4096 was already there as the FTP_BUFSIZE, 2500 maybe a little excesive but in my environment it could get that bad. :/ So I was thinking that maybe I should add a optional flag on ftp_connect on where or not to trace the conversation? Thoughts? Jess -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ftp_get_resp ftp_get_conv functions
Agreed. That was a bad idea. After I slept on it, I regreted sending that, cause the default memory limit is 8M (with the exception of the cli sapi). With no option on whether or not to do the trace and 2500x4096 being a 10M buffer, I imagine just calling ftp_connect would put you over your memory limit. So I will change it to allocate the memory dynamically, and an optional parmeter to ftp_connect on whether or not to do the trace at all. But now I need some advise from you experts... I can't imagine getting a 4k response or sending a 4k command on the control channel of an FTP session. So that is a lot of unused memory, on the other hand, that's how big the input/output buffers are and without knowing what the length of the longest response/command is until the whole conversation is finished, if my string buffer is to small, it will either truncate the string (with proper bounds checking) or create the potential for a buffer overflow. I could check the length of the string and if it is longer than the current length of the string array, then allocate enough memory to hold it, increasing the length of the element for all the other strings. In which case I would think it appropriate to #define MAX_RESP_LENGTH to prevent potential for a DOS. Also allocating N+1 elements every time a command is sent or a response is received would create a ton of overhead because wouldn't I would have to allocate the new buffer, then copy the current buffer in to it resulting in a serious performance hit? Regretfully ignorant, Jess -Original Message- From: Kamesh Jayachandran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 6:57 AM To: Binam, Jesse; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] ftp_get_resp ftp_get_conv functions Hi Jesse, 2500*4096 = 10M on ftpbuf would be too much for the user who is not interested in this functionality. It should be allocating the memory dynamically instead of hardcoding the size to 2500. This need to happen only when requested, may be some option argument to ftp_connect whether to track the ftp conversation. With regards Kamesh Jayachandran On Wed, 15 Dec 2004 21:47:09 -0700, Binam, Jesse [EMAIL PROTECTED] said: The attached diff adds 2 ftp functions. I read the README.SUBMITTING_PATCH and went thru all the steps, but there are no tests for ftp, and I didn't understand how to update the docs. So if someone would like to help me with that, great. Basically, I modifed ftpbuf_t adding a 2 dimensional array (array of strings) to store the conversation, and an int that indicates the next element in first dimension the array. I modified ftp_putcmd and ftp_getresp to add what gets sent/recvd in the conversation. And lastly I added ftp_get_resp which returns the 3 digit return code from the server of the last command sent, and ftp_get_conv (which I would not be opposed to changing the name of, that's just what I came up with) that returns the ftp conversation as an array. Both functions must be called before ftp_close (or ftp_quit) because it frees the resource. The array I defined is 2500x4096. 4096 was already there as the FTP_BUFSIZE, 2500 maybe a little excesive but in my environment it could get that bad. :/ So I was thinking that maybe I should add a optional flag on ftp_connect on where or not to trace the conversation? Thoughts? Jess -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] CVS karma
Which in itself is not a big deal. And I reject more than I approve actually. For a while I tried to verify each one with the documentation project leads, but half the time they wouldn't respond. I am not sure how other people would do a better job vetting these folks. If they don't contribute anything they will be blown away on the next account cleanup sweep. -Rasmus Nuno Lopes wrote: Are you sure? I know that there are some guys that use their account like a free e-mail account redirection. This is because you 'offer' accounts to everybody that wants to join the doc team. Your idea to out-source karma would be good to handle this problems... (I remember to read a mail in the mirrors ML about this...) Nuno - Original Message - That's a lot less critical. I ran a sweep a couple of years ago that deleted a couple of hundred old unused accounts. At some point I will run another one, but having unused accounts sitting around really doesn't affect us in any way. -Rasmus Nuno Lopes wrote: And deletion of current cvs accounts? I've run some stats 6 months ago, and about 50% of phpdoc cvs accounts were never used... Nuno - Original Message - I'd love to outsource that part, but we'd need to modify the tools a bit. Anyway, there was a backlog of 39 cvs account requests. I went through them all and approved about a third of them. -Rasmus Alan Knowles wrote: I'm not sure if it's [EMAIL PROTECTED] or [EMAIL PROTECTED] is the best place for this, but internals may help a bit.. unless they want to outsource the karma mgmt of pear stuff to one of the pear group ;) Regards Alan Jesper Veggerby Hansen wrote: Hi guys, Just wondering if anybody has been able to get a new acccount to CVS the last couple of months? Been trying - with what I was told was the official way - through some page hidden deep in the 42nd link from http://php.net/, but hasn't been able to get the right karma, yet. Anybody been successfull or know of which other buttons to press? I think I did take the red pill. Regards Jesper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Major isssue with foreach() in PHP 4.3.10
On Thu, 16 Dec 2004, Jeremy Johnstone wrote: http://bugs.php.net/bug.php?id=31134 This is breaking a large number of scripts. The bug you have there is a Zend optimizer bug as you conclude yourself. So why bother the mailinglist with it? And yes, there is another foreach bug of you do: foreach($array as $key = $key) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] CVS karma
Rasmus Lerdorf wrote: That's a lot less critical. I ran a sweep a couple of years ago that deleted a couple of hundred old unused accounts. At some point I will run another one, but having unused accounts sitting around really doesn't affect us in any way. Except for a security point of view. But I agree that someone can't do much harm. In any ways, I recall that some people have CVS karma for the comments system on the PHP website. Is it still accurate? If so, it's maybe less than 50%. Sincerely, Olivier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ftp_get_resp ftp_get_conv functions
Check out either the smart_str API or simply log the conversation to a user-supplied stream. --Wez. On Thu, 16 Dec 2004 11:02:43 -0700, Binam, Jesse [EMAIL PROTECTED] wrote: Agreed. That was a bad idea. After I slept on it, I regreted sending that, cause the default memory limit is 8M (with the exception of the cli sapi). With no option on whether or not to do the trace and 2500x4096 being a 10M buffer, I imagine just calling ftp_connect would put you over your memory limit. So I will change it to allocate the memory dynamically, and an optional parmeter to ftp_connect on whether or not to do the trace at all. But now I need some advise from you experts... I can't imagine getting a 4k response or sending a 4k command on the control channel of an FTP session. So that is a lot of unused memory, on the other hand, that's how big the input/output buffers are and without knowing what the length of the longest response/command is until the whole conversation is finished, if my string buffer is to small, it will either truncate the string (with proper bounds checking) or create the potential for a buffer overflow. I could check the length of the string and if it is longer than the current length of the string array, then allocate enough memory to hold it, increasing the length of the element for all the other strings. In which case I would think it appropriate to #define MAX_RESP_LENGTH to prevent potential for a DOS. Also allocating N+1 elements every time a command is sent or a response is received would create a ton of overhead because wouldn't I would have to allocate the new buffer, then copy the current buffer in to it resulting in a serious performance hit? Regretfully ignorant, Jess -Original Message- From: Kamesh Jayachandran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 6:57 AM To: Binam, Jesse; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] ftp_get_resp ftp_get_conv functions Hi Jesse, 2500*4096 = 10M on ftpbuf would be too much for the user who is not interested in this functionality. It should be allocating the memory dynamically instead of hardcoding the size to 2500. This need to happen only when requested, may be some option argument to ftp_connect whether to track the ftp conversation. With regards Kamesh Jayachandran On Wed, 15 Dec 2004 21:47:09 -0700, Binam, Jesse [EMAIL PROTECTED] said: The attached diff adds 2 ftp functions. I read the README.SUBMITTING_PATCH and went thru all the steps, but there are no tests for ftp, and I didn't understand how to update the docs. So if someone would like to help me with that, great. Basically, I modifed ftpbuf_t adding a 2 dimensional array (array of strings) to store the conversation, and an int that indicates the next element in first dimension the array. I modified ftp_putcmd and ftp_getresp to add what gets sent/recvd in the conversation. And lastly I added ftp_get_resp which returns the 3 digit return code from the server of the last command sent, and ftp_get_conv (which I would not be opposed to changing the name of, that's just what I came up with) that returns the ftp conversation as an array. Both functions must be called before ftp_close (or ftp_quit) because it frees the resource. The array I defined is 2500x4096. 4096 was already there as the FTP_BUFSIZE, 2500 maybe a little excesive but in my environment it could get that bad. :/ So I was thinking that maybe I should add a optional flag on ftp_connect on where or not to trace the conversation? Thoughts? Jess -- 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
