[PHP-DEV] Release process (was: Re: [PHP-CVS] cvs: php4 / configure.in /main php_version.h)
I agree that the main issue here the release process. I don't think it's working very well now. How long ago was PHP_4_0_7 branch made? It's not that ecouraging fixing a bug or adding a new feature and telling people that the fix or feature will be released in 6 months or so. So how do we cut the time from branch to release down to 2-4 weeks? Edin - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Stig S. Bakken [EMAIL PROTECTED] Cc: James Cox [EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 15, 2002 10:28 AM Subject: RE: [PHP-CVS] cvs: php4 / configure.in /main php_version.h At 11:09 15/03/2002, Stig S. Bakken wrote: The new versioning scheme is a good idea at the right time. You should give better arguments than the old scheme has (always worked|worked before). And I did (inability to sync multiple trees, lengthy release cycles (from branching to release), userbase perception of what version numbers mean in the OS world, time from introduction of new features, or infrastructure improvements and their delivery to the userbase, legitimizing patch releases by making them look better (there's no excuse for a QA messup, no matter if you call it 4.2.1., 4.2.0pl1 or 5.0.456), and I think there were more). I have no motivation to go into them all over again, and the fact the old scheme worked seemed like a pretty good KISS summary. In reality, if we don't have enough QA resources (and we don't, ask Derick who has to wait for 3 weeks from branching to RC1 (!)), then picking on the versioning scheme is looking for the coin under the light, when it already slipped through the cracks to the sewers. Fix what requires fixing, not the things that are and always have worked. Right now, it appears we're getting the bad of both worlds - we lost the dynamic nature of an OS project (fast turnaround time), but we also don't have commercial grade QA. To the QA people - we appreciate your work, however, there's simply not enough of you. It's not your fault, of course. If we want to do it right, we need to get a strong QA infrastructure, which would allow us to go from branch to release in 2-4 weeks (and then this whole version numbering business loses its point). Solving the problem by legitimizing pl's as 3rd digit releases is perhaps self-convincing, but it doesn't change anything, except for breaking consistency with out versioning scheme. Zeev -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release process (was: Re: [PHP-CVS] cvs: php4 /configure.in /main php_version.h)
On Fri, 15 Mar 2002, Edin Kadribasic wrote: I agree that the main issue here the release process. I don't think it's working very well now. How long ago was PHP_4_0_7 branch made? It's not that ecouraging fixing a bug or adding a new feature and telling people that the fix or feature will be released in 6 months or so. So how do we cut the time from branch to release down to 2-4 weeks? sounds ok to me, i'll mail a faster release schedule later this day and if nobody objects i'll package rc1 tomorrow. Derick Edin - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Stig S. Bakken [EMAIL PROTECTED] Cc: James Cox [EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, March 15, 2002 10:28 AM Subject: RE: [PHP-CVS] cvs: php4 / configure.in /main php_version.h At 11:09 15/03/2002, Stig S. Bakken wrote: The new versioning scheme is a good idea at the right time. You should give better arguments than the old scheme has (always worked|worked before). And I did (inability to sync multiple trees, lengthy release cycles (from branching to release), userbase perception of what version numbers mean in the OS world, time from introduction of new features, or infrastructure improvements and their delivery to the userbase, legitimizing patch releases by making them look better (there's no excuse for a QA messup, no matter if you call it 4.2.1., 4.2.0pl1 or 5.0.456), and I think there were more). I have no motivation to go into them all over again, and the fact the old scheme worked seemed like a pretty good KISS summary. In reality, if we don't have enough QA resources (and we don't, ask Derick who has to wait for 3 weeks from branching to RC1 (!)), then picking on the versioning scheme is looking for the coin under the light, when it already slipped through the cracks to the sewers. Fix what requires fixing, not the things that are and always have worked. Right now, it appears we're getting the bad of both worlds - we lost the dynamic nature of an OS project (fast turnaround time), but we also don't have commercial grade QA. To the QA people - we appreciate your work, however, there's simply not enough of you. It's not your fault, of course. If we want to do it right, we need to get a strong QA infrastructure, which would allow us to go from branch to release in 2-4 weeks (and then this whole version numbering business loses its point). Solving the problem by legitimizing pl's as 3rd digit releases is perhaps self-convincing, but it doesn't change anything, except for breaking consistency with out versioning scheme. Zeev -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release process (was: Re: [PHP-CVS] cvs: php4 / configure.in /main php_version.h)
sounds ok to me, i'll mail a faster release schedule later this day and if nobody objects i'll package rc1 tomorrow. Since we are trying to improve QA I think RC1 (and the rest of them) should be announced on the list and on www.php.net in order to get more people to test it. Are there any reasons not to do this? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release process (was: Re: [PHP-CVS] cvs: php4 /configure.in /main php_version.h)
On Fri, 15 Mar 2002, Edin Kadribasic wrote: sounds ok to me, i'll mail a faster release schedule later this day and if nobody objects i'll package rc1 tomorrow. Since we are trying to improve QA I think RC1 (and the rest of them) should be announced on the list and on www.php.net in order to get more people to test it. Are there any reasons not to do this? It was my original plan, but only if we have a nice system to collect reports (I've been working on that a little). And only RC1 should be publically announced IMO. Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] release process
Hello folks, I promised to send a more detailed mail for the upcoming release process. Please note that this is my view on it :) Timeline 06-02-2002 Branch to PHP_4_2_0 Only fixed / patches approved by the RM maybe merged from HEAD into the release branch. This is to make sure no stray changes in code end up into the branch, which are not correctly tested during the RC process. After the branch point the QA should make a list of what should be tested with more care than normally would have been done. I'll call them 'special' area's from now. Things like the fileuploading stuff should be mentioned here. Also some more tests should be developed/written here. The set of things that follow from this pinpointing operation are the final requirements for this release. When they are solid here, they should not change during the RC process to make sure there is some point we can actually release, and not end up with RC81 or something. Furthermore I think that one person (or two), the Test Master(s) should be responsible to write down and maintain the the final list. 20-02-2002 Release Candidate 1 Ok, time to test the balls out of the RC. During the RC1 period the Critical bugs should be tested, fixed and exterminated. All bugs that are found during this RC1 and that belong to the critical category should be fixed before RC2. All bugs that are found in the HEAD branch and get fixed should be merged into the release branch by the RM. This RC should be tested by QA and PHP-DEV. 03-03-2002 Release Candidate 2 After RC2 is release only severe and/or critical bugs that are found in the HEAD branch should be merged by the Release Master. The main task of RC2 is to test all bugs that are fixed during RC1 and of course more of the 'special areas'. Testing and the collection and ordening of results should be done by PHP-QA. 12-03-2002 Release Candidate 3 / Final RC In the most ideal situation all bugs that should-be-fixed-before-release are found and fixed now. This final RC should be tested by QA and match the requirements set during the period between branch and RC1. 19-03-2002 Prepare release package If no critical bugs are found we can make the release package for the release. If any critical bugs are found, we do a new RC every week. The reason to keep this short is that we actually want a release some day. 22-03-2002 Release of PHP 4.2.0 Work is done, time to release. Classification of bug severities Normal bugs:Well, all little icky things that are not totally ok. Severe bugs:Bugs that deal with major malfunctions in extensions Critical bugs: Bugs that deal with malfuctions in mainstream (either minor or major). Mainstream modules are IMO: session, mysql, gd, odbc, mssql, curl, domxml, imap, ldap, mcrypt, oci8, pcre, pdf, pgsql, standard :), xml and xslt Security related bugs in every extension Crash bugs in the mainstream extensions, or crash bugs that tend to happen a lot in non-mainstream extensions (ie if enabling an extension crashes PHP). Release Master: Derick Rethans Release Bitch: Jani Taskinen Test Master: Position vacant Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process
I promised to send a more detailed mail for the upcoming release process. Please note that this is my view on it :) And your view is off by one month? ;-) [otherwise it looks fine] Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process
On Wed, 6 Mar 2002, Marc Boeren wrote: I promised to send a more detailed mail for the upcoming release process. Please note that this is my view on it :) And your view is off by one month? ;-) Damnit... I thought I fixed that :) Derick -- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 08:48 PM 5/3/2001 -0400, David Croft wrote: In my humble opinion 'null' is a 'pseudovalue' that has been made available for some time. If it was never intended for a script to be able to use it, it should never have been exposed. But it has been and many people, myself included, are using it. That's wrong. It was a new value introduced which was meant to be seen (it was asked for by Thies). But it was meant to be unset. To be quite honest, I don't even quite remember if Zend still uses it for internal values. I think it doesn't anymore. I was just saying that forget the Zend internals, there is a question of semantics one needs to think of. I must admit I haven't had the time to think of this yet in full and I'll think about it again. But although these things always seem trivial to many people you have to understand that sometimes the implications can be much more far reaching than what you think. Also no one has gone through all of the modules and check if we are consistent with when NULL is returned and when not (returned as an array element). It would also help to make a game plan of what to do but I think adding key_exists() without being sure of the whole picture is a mistake. We might end up with the conclusion that this function is the right thing, but it has to be a serious conclusion after checking all of the aspects. Andi It is particularly useful to mark a value that has not yet been filled. The same way NULL is used in SQL. If you take out this behaviour there is no 'pseudo-value' to indicate the absence of value and we will go back to using 0 or constants, a hack at best. Also, I see a distinction semantically between isset and key_exists. Isset asks whether it is set to a tangible value. Key_exists asks whether the array contains an entry, any entry, for that key. My 2 cents, David -- | /+\ \| | | David Croft Infotrek On Thu, 3 May 2001, Zeev Suraski wrote: At 17:20 3/5/2001, Cynic wrote: I very much agree with Andrei on this. Please, keep the existing functionality. Although, I'm not familiar with any issues possibly connected with this. Does it hurt anything? Yes, it requires adding of functions that duplicate isset()'s behavior in a way that may change in the future (implementation dependent). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
Question: Is is_null() an alias for isset()? Based on this statement and my understanding of both funcitons, it should be. Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 07:02 PM 5/3/2001 -0500, Andrei Zmievski wrote: At 06:31 PM 5/3/01 -0500, Richard Lynch wrote: Um, lots of people use isset($row['foo]) to detect NULL in the database... Are you going to change that behaviour? Don't. If the column is missing, they screwed up their SQL, which is not within the pervue of PHP to fix in the first place... You are arguing my point, Richard. Andrei, Not exactly. No matter if it is set to NULL or unset then isset() will give the same result. And most people use isset() AFAIK. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 17:30 4/5/2001, Joe Brown wrote: Question: Is is_null() an alias for isset()? Based on this statement and my understanding of both funcitons, it should be. No it's not, it's a function. As such, it cannot detect whether a variable exists and has a null value, or is undefined completely. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Re: [PHP-QA] Re: [PHP-DEV] Release process
On Fri, 4 May 2001, Zeev Suraski wrote:
At 17:30 4/5/2001, Joe Brown wrote:
Question:
Is is_null() an alias for isset()?
Based on this statement and my understanding of both funcitons, it should
be.
No it's not, it's a function. As such, it cannot detect whether a variable
exists and has a null value, or is undefined completely.
It can if you use it like I have been:
function whatever()
{
$var = NULL;
if (is_null($var)) {
echo variable is null;
}
}
I'm a bit crazy, so I pre-assign a lot of my variables at the top of my
functions (I never could really get used to not pre-declaring
variables)...
-Sterling
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Release process
In an effort to stop a long going ping-pong again, let's concentrate on figuring out what was wrong with the old release, and trying to improve it in the future. I'll start by saying that generally, overall, the last release was pretty good. Ok, so COM didn't work, but only a very small number of people is actually affected by this. Overall, the QA process *worked*. To get to fix the bugs in the QA process, we need to look at the exceptions to the rule, i.e., the things that didn't work out right. The first and obvious example then, would be the COM module. I believe that the main difference in the COM module patches, when compared to other patches, is that it was mainly to implement new functionality, or to rewrite code in a better way. We should probably have a guideline that new code/code rewrite patches should not be submitted to RC branches. Another issue was the inability of people to deliver patches on time. I.e., there were quite a few patches that were important to put in the release (i.e., fixed bugs) but came in after 'the last RC' was announced. That's one of the reasons we had so many 'last RCs' in this RC round. Whether there's a good solution here is not very clear; My guess is that there isn't. The question is whether we should be more aggressive about dates (i.e., if you didn't submit your patch on time, it's your problem) or not. There's no good answer here IMHO, comments welcome... Those were the two main broken things about the last release. Let's concentrate on fixing them instead of rethinking the whole architecture, because it *worked*. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Release process
[Zeev Suraski [EMAIL PROTECTED]] In an effort to stop a long going ping-pong again, let's concentrate on figuring out what was wrong with the old release, and trying to improve it in the future. I'll start by saying that generally, overall, the last release was pretty good. Ok, so COM didn't work, but only a very small number of people is actually affected by this. Overall, the QA process *worked*. To get to fix the bugs in the QA process, we need to look at the exceptions to the rule, i.e., the things that didn't work out right. The first and obvious example then, would be the COM module. I believe that the main difference in the COM module patches, when compared to other patches, is that it was mainly to implement new functionality, or to rewrite code in a better way. We should probably have a guideline that new code/code rewrite patches should not be submitted to RC branches. Another issue was the inability of people to deliver patches on time. I.e., there were quite a few patches that were important to put in the release (i.e., fixed bugs) but came in after 'the last RC' was announced. That's one of the reasons we had so many 'last RCs' in this RC round. Whether there's a good solution here is not very clear; My guess is that there isn't. The question is whether we should be more aggressive about dates (i.e., if you didn't submit your patch on time, it's your problem) or not. There's no good answer here IMHO, comments welcome... Those were the two main broken things about the last release. Let's concentrate on fixing them instead of rethinking the whole architecture, because it *worked*. We need to fix either the scope (bugs that need to be fixed) or the release date, and stick to that. Tradition is to move the release date. If we move both at once, we're in trouble and chances are it will delay the release even more. So, if the showstoppers are identified before rolling the first RC, we can either fix them first, or roll the first RC and fix them all before rolling the second (depending on the general activity on the main trunk, IMHO it would be better to do two RCs). We'll always have the problem of I need to MFH this, pretty please, but I think that started working well at the end of the 4.0.5 QA. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Release process
At 05:52 AM 5/3/2001 -0400, Stig Sæther Bakken wrote: We'll always have the problem of I need to MFH this, pretty please, but I think that started working well at the end of the 4.0.5 QA. :-) I actually also think that on a whole 4.0.5's release process was pretty good and a big improvement on anything we had in the past. That brings me to more current events. I'd like to roll an RC1 for 4.0.6 pretty soon (Saturday?). I think the only fix which really needs to make it in (unless I forgot something) is the libtool detection patch. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
Andi wrote: That brings me to more current events. I'd like to roll an RC1 for 4.0.6 pretty soon (Saturday?). I don't want to slow things down here, and if Saturday can be achieved, all well and good, but we perhaps ought to have a strong guideline that, say, 1 weeks warning of an impending RC is given. That will give everyone time to either get their important stuff in, or argue for a delay, and there will be a lower probability of people wanting to stick stuff in other than bugfixes after RC1. If we can't have a firm rule that only bug fixes go in after RC1, can we at least agree that that is the guideline in upper case bold 72 point flashing red and green text? Cheers -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 11:16 AM 5/3/2001 +0100, Phil Driscoll wrote: Andi wrote: That brings me to more current events. I'd like to roll an RC1 for 4.0.6 pretty soon (Saturday?). I don't want to slow things down here, and if Saturday can be achieved, all well and good, but we perhaps ought to have a strong guideline that, say, 1 weeks warning of an impending RC is given. That will give everyone time to either get their important stuff in, or argue for a delay, and there will be a lower probability of people wanting to stick stuff in other than bugfixes after RC1. I already mailed about it a few days ago. I think a lot of changes have been made since 4.0.5, especially a lot of good bug fixes, and it's a good idea to start getting 4.0.6 out of the door. 4.0.5 branched a looong time ago. If we can't have a firm rule that only bug fixes go in after RC1, can we at least agree that that is the guideline in upper case bold 72 point flashing red and green text? I think that can be done :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 3 May 2001, Phil Driscoll wrote: Andi wrote: That brings me to more current events. I'd like to roll an RC1 for 4.0.6 pretty soon (Saturday?). I don't want to slow things down here, and if Saturday can be achieved, all well and good, but we perhaps ought to have a strong guideline that, say, 1 weeks warning of an impending RC is given. That will give everyone time to either get their important stuff in, or argue for a delay, and there will be a lower probability of people wanting to stick stuff in other than bugfixes after RC1. If we can't have a firm rule that only bug fixes go in after RC1, can we at least agree that that is the guideline in upper case bold 72 point flashing red and green text? I just want to remind everyone that the 4.0.6 is suppose to have mainly bug fixes..or wasn't this agreed on yet? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Release process
What's the status of the show stoppers list James put up? We should fix as many bugs as we can (at least those which are planned to be fixed in 4.0.6) before branching, to avoid having to synchronize two branches for every bug fix. Zeev At 13:04 3/5/2001, Andi Gutmans wrote: At 05:52 AM 5/3/2001 -0400, Stig Sæther Bakken wrote: We'll always have the problem of I need to MFH this, pretty please, but I think that started working well at the end of the 4.0.5 QA. :-) I actually also think that on a whole 4.0.5's release process was pretty good and a big improvement on anything we had in the past. That brings me to more current events. I'd like to roll an RC1 for 4.0.6 pretty soon (Saturday?). I think the only fix which really needs to make it in (unless I forgot something) is the libtool detection patch. Andi -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 13:27 3/5/2001, Jani Taskinen wrote: I just want to remind everyone that the 4.0.6 is suppose to have mainly bug fixes..or wasn't this agreed on yet? Yes it was. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Release process
What's the status of the show stoppers list James put up? We should fix as many bugs as we can (at least those which are planned to be fixed in 4.0.6) before branching, to avoid having to synchronize two branches for every bug fix. Ill go through tonight and update list and post tomorrow. I also feel the Com problem is a showstopper and that NEDDS to be fixed before 4.0.6.. I have 6 emails from people at PHP_UK etc asking if it will be fixed in 4.0.6 etc. Lets not let the 99% of people use PHP on linux lets ignore the windows users ethos of many opensource projects happen here too. We try to be crossplatform lets make sure we are and get the COM thing fixed too. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Release process
At 12:52 PM 5/3/2001 +0100, James Moore wrote: What's the status of the show stoppers list James put up? We should fix as many bugs as we can (at least those which are planned to be fixed in 4.0.6) before branching, to avoid having to synchronize two branches for every bug fix. Ill go through tonight and update list and post tomorrow. I also feel the Com problem is a showstopper and that NEDDS to be fixed before 4.0.6.. I have 6 emails from people at PHP_UK etc asking if it will be fixed in 4.0.6 etc. Lets not let the 99% of people use PHP on linux lets ignore the windows users ethos of many opensource projects happen here too. We try to be crossplatform lets make sure we are and get the COM thing fixed too. It seems to be fixed already. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Release process
What's the status of the show stoppers list James put up? We should fix as many bugs as we can (at least those which are planned to be fixed in 4.0.6) before branching, to avoid having to synchronize two branches for every bug fix. Ill go through tonight and update list and post tomorrow. I also feel the Com problem is a showstopper and that NEDDS to be fixed before 4.0.6.. I have 6 emails from people at PHP_UK etc asking if it will be fixed in 4.0.6 etc. Lets not let the 99% of people use PHP on linux lets ignore the windows users ethos of many opensource projects happen here too. We try to be crossplatform lets make sure we are and get the COM thing fixed too. It seems to be fixed already. The patch was just reverted it wasnt fixed.. I think... - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Release process
At 12:58 PM 5/3/2001 +0100, James Moore wrote: What's the status of the show stoppers list James put up? We should fix as many bugs as we can (at least those which are planned to be fixed in 4.0.6) before branching, to avoid having to synchronize two branches for every bug fix. Ill go through tonight and update list and post tomorrow. I also feel the Com problem is a showstopper and that NEDDS to be fixed before 4.0.6.. I have 6 emails from people at PHP_UK etc asking if it will be fixed in 4.0.6 etc. Lets not let the 99% of people use PHP on linux lets ignore the windows users ethos of many opensource projects happen here too. We try to be crossplatform lets make sure we are and get the COM thing fixed too. It seems to be fixed already. The patch was just reverted it wasnt fixed.. I think... Well the COM extension works now. As far as I'm concerned it's fixed :) I don't know if he reverted the whole thing or just part of it. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Release process
[Andi Gutmans [EMAIL PROTECTED]] At 05:52 AM 5/3/2001 -0400, Stig Sæther Bakken wrote: We'll always have the problem of I need to MFH this, pretty please, but I think that started working well at the end of the 4.0.5 QA. :-) I actually also think that on a whole 4.0.5's release process was pretty good and a big improvement on anything we had in the past. That brings me to more current events. I'd like to roll an RC1 for 4.0.6 pretty soon (Saturday?). I think the only fix which really needs to make it in (unless I forgot something) is the libtool detection patch. So we'll use a codename for it that will the third noun on page 5 of sunday's morning paper in Trondheim (as was agreed by lack of protest a few weeks ago ;-). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Release process
[Oyvind Moll [EMAIL PROTECTED]] * Stig Sæther Bakken [EMAIL PROTECTED] | | sunday's morning paper in Trondheim That won't be much of a name. (...or has Adresseavisa started printing a Sunday edition?) That was of course supposed to be saturday. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Zeev Suraski wrote: At 13:27 3/5/2001, Jani Taskinen wrote: I just want to remind everyone that the 4.0.6 is suppose to have mainly bug fixes..or wasn't this agreed on yet? Yes it was. Does that mean I should take my array_map() and array_filter() functions out? ;-) -Andrei * What were the first 15 billion years of the universe like for you? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 08:35 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Zeev Suraski wrote: At 13:27 3/5/2001, Jani Taskinen wrote: I just want to remind everyone that the 4.0.6 is suppose to have mainly bug fixes..or wasn't this agreed on yet? Yes it was. Does that mean I should take my array_map() and array_filter() functions out? ;-) Nah but I think it means that you shouldn't add any more array_foobar() functions before 4.0.7-dev :) By the way, what happened to that array_defined() or whatever function which was added? Didn't we say it should be nuked? isset() and empty() are enough IMO especially as NULL is used as undefined. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Andi Gutmans wrote: Nah but I think it means that you shouldn't add any more array_foobar() functions before 4.0.7-dev :) Geez, just when I finished array_foobar().. By the way, what happened to that array_defined() or whatever function which was added? Didn't we say it should be nuked? isset() and empty() are enough IMO especially as NULL is used as undefined. key_exists(), you mean? I didn't put it in, and as far as I know it's still there. -Andrei Windows 2000 is certified not to crash more than once a day, so what is the bootup time, 24 hours? -- Sam Liddicott -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 08:45 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: Nah but I think it means that you shouldn't add any more array_foobar() functions before 4.0.7-dev :) Geez, just when I finished array_foobar().. :) By the way, what happened to that array_defined() or whatever function which was added? Didn't we say it should be nuked? isset() and empty() are enough IMO especially as NULL is used as undefined. key_exists(), you mean? I didn't put it in, and as far as I know it's still there. I'd really like to nuke it. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Andi Gutmans wrote: key_exists(), you mean? I didn't put it in, and as far as I know it's still there. I'd really like to nuke it. I can sort of see his point really, if $array['foo'] = NULL there is no way to know whether key 'foo' exists or not.. -Andrei * Power corrupts. Atomic power corrupts atomically. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 16:46 3/5/2001, Andi Gutmans wrote: By the way, what happened to that array_defined() or whatever function which was added? Didn't we say it should be nuked? isset() and empty() are enough IMO especially as NULL is used as undefined. key_exists(), you mean? I didn't put it in, and as far as I know it's still there. I'd really like to nuke it. Without commenting on whether it should be nuked or not, there's no way to implement this functionality with isset() and empty(). Neither of these constructs can be used to figure out whether an element exists and is null. Whether or not this should be detectable is a different issue... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 08:48 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: key_exists(), you mean? I didn't put it in, and as far as I know it's still there. I'd really like to nuke it. I can sort of see his point really, if $array['foo'] = NULL there is no way to know whether key 'foo' exists or not.. Yeah but I'm afraid it'll make scripts be written on behavior which shouldn't be counted on. Maybe in future versions of Zend $array['foo'] won't be defined. There are certain situations where I think it was impossible to not define it so it was defined with NULL meaning it's not defined. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Andi Gutmans wrote: Yeah but I'm afraid it'll make scripts be written on behavior which shouldn't be counted on. Maybe in future versions of Zend $array['foo'] won't be defined. There are certain situations where I think it was impossible to not define it so it was defined with NULL meaning it's not defined. Um, but some db extensions return NULL values as part of the array, so if column 'foo' is NULL in the db, you'd want the result array to have NULL under key 'foo' - it just won't do to have that column be missing. -Andrei * We reason deeply, when we forcibly feel. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 08:53 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: Yeah but I'm afraid it'll make scripts be written on behavior which shouldn't be counted on. Maybe in future versions of Zend $array['foo'] won't be defined. There are certain situations where I think it was impossible to not define it so it was defined with NULL meaning it's not defined. Um, but some db extensions return NULL values as part of the array, so if column 'foo' is NULL in the db, you'd want the result array to have NULL under key 'foo' - it just won't do to have that column be missing. Yeah but you can use === NULL for those. You might be right but I remember we decided it's problematic. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
Err, as you say, PHP should make things easy. I don't see how making tell NULL from an undefined variable makes anything easier. At 15:49 3.5. 2001, Andi Gutmans wrote the following: -- At 08:48 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: key_exists(), you mean? I didn't put it in, and as far as I know it's still there. I'd really like to nuke it. I can sort of see his point really, if $array['foo'] = NULL there is no way to know whether key 'foo' exists or not.. Yeah but I'm afraid it'll make scripts be written on behavior which shouldn't be counted on. Maybe in future versions of Zend $array['foo'] won't be defined. There are certain situations where I think it was impossible to not define it so it was defined with NULL meaning it's not defined. Andi -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
Hmmm, looks like the MySQL module was changed to add NULL elements to the array. It even looks as if you changed it :) I intentionally removed the code that populated return values with NULL's, to avoid inconsistencies. People should use the mysql_fetch_field() to check which fields there are. I'd like to change it back... Zeev At 16:53 3/5/2001, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: Yeah but I'm afraid it'll make scripts be written on behavior which shouldn't be counted on. Maybe in future versions of Zend $array['foo'] won't be defined. There are certain situations where I think it was impossible to not define it so it was defined with NULL meaning it's not defined. Um, but some db extensions return NULL values as part of the array, so if column 'foo' is NULL in the db, you'd want the result array to have NULL under key 'foo' - it just won't do to have that column be missing. -Andrei * We reason deeply, when we forcibly feel. * -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Zeev Suraski wrote: Hmmm, looks like the MySQL module was changed to add NULL elements to the array. It even looks as if you changed it :) I intentionally removed the code that populated return values with NULL's, to avoid inconsistencies. People should use the mysql_fetch_field() to check which fields there are. I'd like to change it back... Yes, I changed it a while ago because it seems logical that the result array should be representative of what is in the database. If I run a query select field1, field2, field3 from table, then I'd better have all three fields in the result array, rather than hunting for which field was omitted. -Andrei Freedom comes when you learn to let go. Creation comes when you learn to say no. -madonna -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
insert impossible somewhere in the sentence to make it make sense. At 16:04 3.5. 2001, Cynic wrote the following: -- Err, as you say, PHP should make things easy. I don't see how making tell NULL from an undefined variable makes anything easier. At 15:49 3.5. 2001, Andi Gutmans wrote the following: -- At 08:48 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: key_exists(), you mean? I didn't put it in, and as far as I know it's still there. I'd really like to nuke it. I can sort of see his point really, if $array['foo'] = NULL there is no way to know whether key 'foo' exists or not.. Yeah but I'm afraid it'll make scripts be written on behavior which shouldn't be counted on. Maybe in future versions of Zend $array['foo'] won't be defined. There are certain situations where I think it was impossible to not define it so it was defined with NULL meaning it's not defined. Andi -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
I very much agree with Andrei on this. Please, keep the existing functionality. Although, I'm not familiar with any issues possibly connected with this. Does it hurt anything? At 16:03 3.5. 2001, Andrei Zmievski wrote the following: -- On Thu, 03 May 2001, Zeev Suraski wrote: Hmmm, looks like the MySQL module was changed to add NULL elements to the array. It even looks as if you changed it :) I intentionally removed the code that populated return values with NULL's, to avoid inconsistencies. People should use the mysql_fetch_field() to check which fields there are. I'd like to change it back... Yes, I changed it a while ago because it seems logical that the result array should be representative of what is in the database. If I run a query select field1, field2, field3 from table, then I'd better have all three fields in the result array, rather than hunting for which field was omitted. -Andrei Freedom comes when you learn to let go. Creation comes when you learn to say no. -madonna -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 17:20 3/5/2001, Cynic wrote: I very much agree with Andrei on this. Please, keep the existing functionality. Although, I'm not familiar with any issues possibly connected with this. Does it hurt anything? Yes, it requires adding of functions that duplicate isset()'s behavior in a way that may change in the future (implementation dependent). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Zeev Suraski wrote: Yes, it requires adding of functions that duplicate isset()'s behavior in a way that may change in the future (implementation dependent). What do you mean? You won't be able to store NULL's in the arrays? -Andrei * I don't mind going nowhere as long as it's an interesting path. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process
On Thu, 3 May 2001, Zeev Suraski wrote: At 17:20 3/5/2001, Cynic wrote: I very much agree with Andrei on this. Please, keep the existing functionality. Although, I'm not familiar with any issues possibly connected with this. Does it hurt anything? Yes, it requires adding of functions that duplicate isset()'s behavior in a way that may change in the future (implementation dependent). Could this possible change be delayed to 4.1 ? As this will definately break A LOT of scripts if it's changed. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 10:43 AM 5/3/2001 -0400, Joe Brown wrote: What about an isnull() function, opposed to key_exists(); IsPossible()? Yeah that's definitely a possiblity but then you'd have to do something like. if (isset($a[foo]) || isnull($a[foo)) Kind of sucky. But we should think of a good resolution for a major version. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
No plans to do anything at this point. You can keep all your hairs in tact :) Zeev At 17:42 3/5/2001, Jani Taskinen wrote: On Thu, 3 May 2001, Zeev Suraski wrote: At 17:20 3/5/2001, Cynic wrote: I very much agree with Andrei on this. Please, keep the existing functionality. Although, I'm not familiar with any issues possibly connected with this. Does it hurt anything? Yes, it requires adding of functions that duplicate isset()'s behavior in a way that may change in the future (implementation dependent). Could this possible change be delayed to 4.1 ? As this will definately break A LOT of scripts if it's changed. --Jani -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
RTFM :)) http://www.php.net/manual/en/html/function.is-null.html At 16:47 3.5. 2001, Andi Gutmans wrote the following: -- At 10:43 AM 5/3/2001 -0400, Joe Brown wrote: What about an isnull() function, opposed to key_exists(); IsPossible()? Yeah that's definitely a possiblity but then you'd have to do something like. if (isset($a[foo]) || isnull($a[foo)) Kind of sucky. But we should think of a good resolution for a major version. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process
On Thu, 3 May 2001, Andi Gutmans wrote:
At 10:43 AM 5/3/2001 -0400, Joe Brown wrote:
What about an isnull() function, opposed to key_exists();
IsPossible()?
Yeah that's definitely a possiblity but then you'd have to do something like.
if (isset($a[foo]) || isnull($a[foo))
Kind of sucky.
But we should think of a good resolution for a major version.
IsAvailable()
[sterling@localhost standard]$ grep is_null *
basic_functions.c: PHP_FE(is_null,
first_arg_allow_ref)
basic_functions.c:/* {{{ proto bool is_null(mixed var)
basic_functions.c:PHP_FUNCTION(is_null)
basic_functions.h:PHP_FUNCTION(is_null);
grep: CVS: Is a directory
grep: tests: Is a directory
[sterling@localhost standard]$
I added it in 4.0.4
-Sterling
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
If $a is undefined and you do is_null($a) I supposed you get true. I was talking about a language construct which will give false in this case. Anyway, it's not something I think we should change right now. I think Andrei's MySQL patch should be reverted though. Many people are doing isset($row[foo]) on their MySQL query results. Today if foo is NULL it will return false. If this is ever changed (some people thing it should) it will return true. So why not change the MySQL module back to the way it was? It worked for everyone and it might allow us to make this change in future. Andi At 05:16 PM 5/3/2001 +0200, Cynic wrote: RTFM :)) http://www.php.net/manual/en/html/function.is-null.html At 16:47 3.5. 2001, Andi Gutmans wrote the following: -- At 10:43 AM 5/3/2001 -0400, Joe Brown wrote: What about an isnull() function, opposed to key_exists(); IsPossible()? Yeah that's definitely a possiblity but then you'd have to do something like. if (isset($a[foo]) || isnull($a[foo)) Kind of sucky. But we should think of a good resolution for a major version. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 11:01 PM 5/2/2001 -0400, Sterling Hughes wrote:
IsAvailable()
[sterling@localhost standard]$ grep is_null *
basic_functions.c: PHP_FE(is_null,
first_arg_allow_ref)
basic_functions.c:/* {{{ proto bool is_null(mixed var)
basic_functions.c:PHP_FUNCTION(is_null)
basic_functions.h:PHP_FUNCTION(is_null);
grep: CVS: Is a directory
grep: tests: Is a directory
[sterling@localhost standard]$
I added it in 4.0.4
See my Email :)
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Andi Gutmans wrote: Anyway, it's not something I think we should change right now. I think Andrei's MySQL patch should be reverted though. Many people are doing isset($row[foo]) on their MySQL query results. Today if foo is NULL it will return false. If this is ever changed (some people thing it should) it will return true. So why not change the MySQL module back to the way it was? It worked for everyone and it might allow us to make this change in future. Ok, why do people do isset($row['foo'])? Also, have you seen people complain about my patch to MySQL that adds NULL's to the result set? -Andrei Linux is like living in a teepee. No Windows, no Gates, Apache in house. - Usenet signature -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 10:17 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: Anyway, it's not something I think we should change right now. I think Andrei's MySQL patch should be reverted though. Many people are doing isset($row[foo]) on their MySQL query results. Today if foo is NULL it will return false. If this is ever changed (some people thing it should) it will return true. So why not change the MySQL module back to the way it was? It worked for everyone and it might allow us to make this change in future. Ok, why do people do isset($row['foo'])? To see if it's NULL. Also, have you seen people complain about my patch to MySQL that adds NULL's to the result set? No because isset() returns false for NULL values. But many people would like it to return true, and then it would break people's scripts. I guess at that point we could change the MySQL module back and not really break people's scripts. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 18:17 3/5/2001, Andrei Zmievski wrote: Also, have you seen people complain about my patch to MySQL that adds NULL's to the result set? Sure. I just did. :) Adding an isnull() language construct may be the right way to solve this situation; key_exists() and the today's function is_null() are both functions that duplicate language-level functionality, and shouldn't exist IMHO. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Andi Gutmans wrote: Also, have you seen people complain about my patch to MySQL that adds NULL's to the result set? No because isset() returns false for NULL values. But many people would like it to return true, and then it would break people's scripts. I guess at that point we could change the MySQL module back and not really break people's scripts. I have a definite need to know whether $row['foo'] is NULL or not. Can you propose a solution towards that? If you revert the patch, then the result set will look as if column 'foo' was never returned. -Andrei * Proximity bug: when the program crashes in front of important visitors. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Zeev Suraski wrote: Sure. I just did. :) Adding an isnull() language construct may be the right way to solve this situation; key_exists() and the today's function is_null() are both functions that duplicate language-level functionality, and shouldn't exist IMHO. Why can't language construct be called is_null()? :) -Andrei * I wish life had an UNDO function. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 10:24 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: Also, have you seen people complain about my patch to MySQL that adds NULL's to the result set? No because isset() returns false for NULL values. But many people would like it to return true, and then it would break people's scripts. I guess at that point we could change the MySQL module back and not really break people's scripts. I have a definite need to know whether $row['foo'] is NULL or not. Can you propose a solution towards that? If you revert the patch, then the result set will look as if column 'foo' was never returned. How do you know today if it's NULL or not? You can't really tell. It does effect array traversal. I'm not saying it's right or wrong now. I'm just trying to think ahead especially as there are mixed feelings about how NULL should behave. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 18:25 3/5/2001, Andrei Zmievski wrote: On Thu, 03 May 2001, Zeev Suraski wrote: Sure. I just did. :) Adding an isnull() language construct may be the right way to solve this situation; key_exists() and the today's function is_null() are both functions that duplicate language-level functionality, and shouldn't exist IMHO. Why can't language construct be called is_null()? :) I wasn't talking about the name, only about the fact that it's implemented as a function and not as a language construct (i.e., it can't tell the difference between existing variables who have the null value, and non existing variables). It's too late to start putting _'s in language constructs, we already have isset() as a precedent :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Andi Gutmans wrote: How do you know today if it's NULL or not? is_null()? -Andrei We all have photographic memories, it's just that some of us don't have any film. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 10:38 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: How do you know today if it's NULL or not? is_null()? is_null() will also return true if it's undefined. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
is_null() should return false if a variable is not set. isset() should be used to test for variables existance, not is_null(). This is my opinion and I'm sticking to it. Those whom deviate from my opinion are wrong in my opinion!!! -Joe Andi Gutmans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 10:38 AM 5/3/2001 -0500, Andrei Zmievski wrote: On Thu, 03 May 2001, Andi Gutmans wrote: How do you know today if it's NULL or not? is_null()? is_null() will also return true if it's undefined. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 01:04 PM 5/3/2001 -0400, Joe Brown wrote: is_null() should return false if a variable is not set. Well it doesn't. There ya go :) isset() should be used to test for variables existance, not is_null(). This is my opinion and I'm sticking to it. Those whom deviate from my opinion are wrong in my opinion!!! Yes sir! Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
On Thu, 03 May 2001, Andi Gutmans wrote: Yeah but I'm afraid it'll make scripts be written on behavior which shouldn't be counted on. Maybe in future versions of Zend $array['foo'] won't be defined. There are certain situations where I think it was impossible to not define it so it was defined with NULL meaning it's not defined. Um, but some db extensions return NULL values as part of the array, so if column 'foo' is NULL in the db, you'd want the result array to have NULL under key 'foo' - it just won't do to have that column be missing. Um, lots of people use isset($row['foo]) to detect NULL in the database... Are you going to change that behaviour? Don't. If the column is missing, they screwed up their SQL, which is not within the pervue of PHP to fix in the first place... -- WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED] Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 06:31 PM 5/3/01 -0500, Richard Lynch wrote: Um, lots of people use isset($row['foo]) to detect NULL in the database... Are you going to change that behaviour? Don't. If the column is missing, they screwed up their SQL, which is not within the pervue of PHP to fix in the first place... You are arguing my point, Richard. -Andrei -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 07:02 PM 5/3/2001 -0500, Andrei Zmievski wrote: At 06:31 PM 5/3/01 -0500, Richard Lynch wrote: Um, lots of people use isset($row['foo]) to detect NULL in the database... Are you going to change that behaviour? Don't. If the column is missing, they screwed up their SQL, which is not within the pervue of PHP to fix in the first place... You are arguing my point, Richard. Andrei, Not exactly. No matter if it is set to NULL or unset then isset() will give the same result. And most people use isset() AFAIK. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 03:14 AM 5/4/01 +0300, Andi Gutmans wrote: Not exactly. No matter if it is set to NULL or unset then isset() will give the same result. And most people use isset() AFAIK. Whatever the current situation, there needs to be a way to check whether a certain array entry is NULL or not. -Andrei -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process
At 07:16 PM 5/3/2001 -0500, Andrei Zmievski wrote: At 03:14 AM 5/4/01 +0300, Andi Gutmans wrote: Not exactly. No matter if it is set to NULL or unset then isset() will give the same result. And most people use isset() AFAIK. Whatever the current situation, there needs to be a way to check whether a certain array entry is NULL or not. If so then we need to make sure that modules like the MySQL module still continue to behave exactly like they used to with isset() and other ways programmers were working. I'm not saying you're wrong. It's probably a good idea but we need to think about the consequences and other changes we might need to make at the same time before breaking stuff. We should probably save all of the NULL stuff for 4.1.x. If we do it the right way we might end up breaking certain scripts. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process
On Thu, 3 May 2001, Andi Gutmans wrote:
At 08:53 AM 5/3/2001 -0500, Andrei Zmievski wrote:
Um, but some db extensions return NULL values as part of the array, so
if column 'foo' is NULL in the db, you'd want the result array to have
NULL under key 'foo' - it just won't do to have that column be missing.
Yeah but you can use === NULL for those.
You might be right but I remember we decided it's problematic.
With all due respect Andi, you can't. There is a difference between a
field being null and that field not existing at all that neither isset,
empty nor === will detect.
david@papaya:~$ php
?
$arr['field'] = null;
$r1 = ($arr['field'] === null);
$r2 = ($arr['blah'] === null);
var_dump($r1);
var_dump($r2);
$r1 = (isset($arr['field']));
$r2 = (isset($arr['blah']));
var_dump($r1);
var_dump($r2);
$r1 = (empty($arr['field']));
$r2 = (empty($arr['blah']));
var_dump($r1);
var_dump($r2);
$r1 = (key_exists('field', $arr));
$r2 = (key_exists('blah', $arr));
var_dump($r1);
var_dump($r2);
?
Out of the four, only key_exists makes the distinction.
I know you had mentioned a problem with Zend not being able to unset
certain fields and instead setting them to null. May I suggest instead
that be attended to - if nothing else, by adding a new 'does not exist'
marker to the bucket that the zend_hash_ functions will recognize.
In the meantime a very large note can be added to the documentation if you
are able to determine exactly what circumstances cause this behaviour.
Cheers,
David
--
| /+\ \| | |
David Croft
Infotrek
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process
In my humble opinion 'null' is a 'pseudovalue' that has been made available for some time. If it was never intended for a script to be able to use it, it should never have been exposed. But it has been and many people, myself included, are using it. It is particularly useful to mark a value that has not yet been filled. The same way NULL is used in SQL. If you take out this behaviour there is no 'pseudo-value' to indicate the absence of value and we will go back to using 0 or constants, a hack at best. Also, I see a distinction semantically between isset and key_exists. Isset asks whether it is set to a tangible value. Key_exists asks whether the array contains an entry, any entry, for that key. My 2 cents, David -- | /+\ \| | | David Croft Infotrek On Thu, 3 May 2001, Zeev Suraski wrote: At 17:20 3/5/2001, Cynic wrote: I very much agree with Andrei on this. Please, keep the existing functionality. Although, I'm not familiar with any issues possibly connected with this. Does it hurt anything? Yes, it requires adding of functions that duplicate isset()'s behavior in a way that may change in the future (implementation dependent). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
