Re: [PHP-DEV] Should I fix this?
Marcus Börger schrieb: At 01:43 07.01.2003, Rickard Andersson wrote: getimagesize() blindly trusts the width and height specified in the header of gifs. You can just hexedit the file and set the width and height to any value and getimagesize() will believe that is the true size of the image. Even worse - Internet Explorer ignores the width and height in the header I'd be glad to write a patch for image.c (function php_handle_gif()), but I though I should ask you guys first. I wouldn't want to do it in vain. As it is now I've got PHP code that checks this for me to prevent malicious users from uploading huge avatars in my forum software. Your scenario described above seems like a reason to accept the the speed loss. So send an unified patch and we will have a look on it. Marcus: could you specify the speed loss? If it's noticeable I would rather suggest to either introduce a new function or another parameter to getimagesize(), no matter what the default is (e.g. let getimagesize() get the real size and introduce something like getimagesize_fast()) or the other way around. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI (compromise proposal)
-Original Message- From: Edin Kadribasic [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 3:34 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] CGI and CLI (compromise proposal) After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. I think this is the best idea so far as it can be implemented (and released ;) fast, would not break BC and gives people who want to use the cli-version to use php. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. MfG, Sebastian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: CGI and CLI
-Original Message- From: Christoph Grottolo [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:39 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Re: CGI and CLI Hi Andrei Zmievski wrote: What was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear. -Andrei I've seen that install.txt has already been adapted to the new cgi version (php.exe has been replaced by php-cgi.exe), however the manual only mentions the eventual name change in chapter 23 about CLI (http://www.php.net/manual/en/features.commandline.php) but not in http://www.php.net/manual/en/install.windows.php. Please consider this whatever the result of the discussions will be. As seen with register_globals, no one reads release notes or readmes. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:50 PM To: Sebastian Nohn Cc: PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Sebastian Nohn wrote: -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. The best solution would be indeed bundling both to one binary. If this delays a 4.3.0-release? I don't give a damn about it! The idea release fast, release often is completely ridiculous in my eyes. If you would like to release 4.3.0 as soon as possible simply let php be php (i talk about the cgi-version), mark cgi still as experimental and work on the integration to one binary for 4.3.1 or 5.0.0. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
Again: Thousands if not millions of servers use PHP as CGI. Who uses PHP for CLI-apps? 100? 1000? 5000? If you use experimental technology you always MUST have in mind that anything can change anytime. Why was'nt PHP available for Apache 2 for a long time (is it in the meantime btw.?)?. Because Apache Group continiously changed their API. -Original Message- From: Xavier Spriet [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:53 PM To: Sebastian Nohn Cc: Sterling Hughes; Andrei Zmievski; PHP Developers Subject: RE: [PHP-DEV] CGI and CLI Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... On Wed, 2002-12-18 at 15:48, Sebastian Nohn wrote: -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 9:30 PM To: Xavier Spriet Cc: Andrei Zmievski; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI This note from Derick pretty much reflects the idea... it makes sense: quote I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. MfG, Sebastian -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:03 PM To: Andrei Zmievski; Xavier Spriet Cc: Sebastian Nohn; Sterling Hughes; PHP Developers Subject: Re: [PHP-DEV] CGI and CLI At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) +1 Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:05 PM To: Andi Gutmans Cc: PHP Developers Subject: Re: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Andi Gutmans wrote: At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) [derick@saturnus php-4.2.1]$ ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 11 13:24 sapi/cli/php That's not the issue. The point is that cgi-version will be renamed to php-cgi, breaking a lot of installations = hundreds of new bogus bugs. Again: nobody reads release-notes. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:14 PM To: Sebastian Nohn Cc: PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Sebastian Nohn wrote: On Wed, 18 Dec 2002, Sebastian Nohn wrote: This note from Derick pretty much reflects the idea... it makes sense: quote I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). /quote Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? I think a lot more users will be pissed of when renaming php to php-cgi than regarding to the cli-version of php as php-cli or phpsh or anything else. I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. But renaming php-cli to php means renaming php to anything else (php-cgi, cgi-php, phpcgi, phpfoo, whatever), right? Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:20 PM To: Sebastian Nohn Cc: Andi Gutmans; PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Sebastian Nohn wrote: -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:05 PM To: Andi Gutmans Cc: PHP Developers Subject: Re: [PHP-DEV] CGI and CLI On Wed, 18 Dec 2002, Andi Gutmans wrote: At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote: On Wed, 18 Dec 2002, Xavier Spriet wrote: Experimental or not, people use it and have developed a need for it. Many apps out there are based on experimental technology, that's not a reason to break them all... So I strongly suggest that whoever has the necessary knowledge on how to merge CGI and CLI back together come forward and do this. Let's get 4.3.0 out the door and move on to the new great things. I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) [derick@saturnus php-4.2.1]$ ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 11 13:24 sapi/cli/php That's not the issue. The point is that cgi-version will be renamed to php-cgi, breaking a lot of installations = hundreds of new bogus bugs. Hello there? I didn't not say that we should rename the php CGI to php-cgi. But you said a php-cli would piss of some users: -- cut here --- Hrmm, how does renaming php-cli break compatibility between PHP _releases_? In no way! PHP-CLI always was marked as experimental. And that means you can piss of users as you see fit? -- cut here --- Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CGI and CLI
-Original Message- From: Xavier Spriet [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 10:25 PM To: Sebastian Nohn Cc: Sterling Hughes; Andrei Zmievski; PHP Developers Subject: RE: [PHP-DEV] CGI and CLI On Wed, 2002-12-18 at 16:17, Sebastian Nohn wrote: Again: Thousands if not millions of servers use PHP as CGI. PHP-CGI will _NOT_ be renamed either. For clearness: The cgi-version of php will be called php-cgi? If this stands firm, why this discussion? Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php-cgi vs php-cli naming issue
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 15, 2002 7:21 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 'Stig S. Bakken'; 'Sterling Hughes'; 'Andrei Zmievski'; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] php-cgi vs php-cli naming issue On Sun, 15 Dec 2002, Marcus Börger wrote: At 18:33 15.12.2002, John Coggeshall wrote: I see that renaming the CGI to php-cgi might break things indeed, and that's never a good idea. But so is changing the name of the CLI (php) to something else. It also breaks things, not only for me, but also for countless others using the CLI with the name 'php'. We also need to think about these users as well. This leaves my opinion that i'm -1 on renaming the CLI to something else, and i'm a -0 (yes this changed :) on renaming the CGI. This leaves the (IMO) only possible solution: integrate them back into one binary and adding some magic which triggers CLI or CGI mode (perhaps to check for some environment variable). I'm a bit nervous about the checking of an environment variable thing. Is that platform/server independent? No, CGI is a well described standard. The only problem there is when someone experiments with the combined executable as a CGI with setting such vars and then forgets to remove the vars after testing is done. In this case he has changed the behaviour of his CLI executable. By environment variables I meant thing that get set for the CGI itnerface. From http://hoohoo.ncsa.uiuc.edu/cgi/env.html you can read that the GATEWAY_INTERFACE is available for all requests, so it's safe to test if this one exists. So i am against comining them back. Besides that i fear that we would have to restart release cycle... The release cycle would be a problem indeed... Why do we need new releases every couple of weeks? Don't misunderstand me, I would really like to see 4.3 released, as this is the first version since around one year that will have only a few bugs on Tru64, on the other hand I'm really shocked, how buggy 4.3 will be on windows (http://lists.php.net/article.php?group=php.qaarticle=7279). I do not develop on windows, so I have no idea if PHP always was so buggy on windows, but in my eyes 4.3 is far from being ready to be released if you take the windows-versions. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php 4.3.0RC3/tru64 test report
=
FAILED TEST SUMMARY
-
OpenSSL private key functions [ext/openssl/tests/001.phpt]
getopt [ext/standard/tests/general_functions/getopt.phpt]
Simple math tests [ext/standard/tests/math/abs.phpt]
log() tests [ext/standard/tests/math/log.phpt]
Various pow() tests [ext/standard/tests/math/pow.phpt]
Simple math tests [ext/standard/tests/math/round.phpt]
microtime() function [ext/standard/tests/time/001.phpt]
strtotime() function [ext/standard/tests/time/002.phpt]
=
/usr/users/nohn/php-4.3.0RC3/ext/openssl/tests/001.phpt
EXPECTED OUTPUT
Creating private key
Export key to file
Load key from file - array syntax
Load key using direct syntax
Load key manually and use string syntax
OK!
ACTUAL OUTPUT
Creating private key
Warning: unable to load random state; not enough random data! in
/usr/users/nohn/php-4.3.0RC3/ext/openssl/tests/001.php on line 4
failed to create private key
FAILED
002- Export key to file
002+
003- Load key from file - array syntax
003+ Warning: unable to load random state; not enough random data! in
/usr/users/nohn/php-4.3.0RC3/ext/openssl/tests/001.php on line 4
004- Load key using direct syntax
004+ failed to create private key
005- Load key manually and use string syntax
006- OK!
/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/general_functions/getopt.phpt
EXPECTED OUTPUT
array(5) {
[v]=
bool(false)
[h]=
bool(false)
[d]=
string(4) test
[m]=
string(4) 1234
[t]=
bool(false)
}
ACTUAL OUTPUT
array(0) {
}
FAILED
001- array(5) {
001+ array(0) {
002- [v]=
002+ }
003- bool(false)
004- [h]=
005- bool(false)
006- [d]=
007- string(4) test
008- [m]=
009- string(4) 1234
010- [t]=
011- bool(false)
012- }
/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/math/abs.phpt
EXPECTED OUTPUT
1,1,0,0
OK
ACTUAL OUTPUT
1,1,1,1
Assert failed:
-LONG_MIN+1 === abs(LONG_MIN-1)
Left: int(-9223372036854775807)
Right: int(9223372036854775807)
Assert failed:
-LONG_MIN === abs(LONG_MIN)
Left: int(-9223372036854775808)
Right: float(9.22337203685E+18)
FAILED
001- 1,1,0,0
001+ 1,1,1,1
002- OK
002+
003+ Assert failed:
004+ -LONG_MIN+1 === abs(LONG_MIN-1)
005+ Left: int(-9223372036854775807)
006+ Right: int(9223372036854775807)
007+
008+ Assert failed:
009+ -LONG_MIN === abs(LONG_MIN)
010+ Left: int(-9223372036854775808)
011+ Right: float(9.22337203685E+18)
/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/math/log.phpt
EXPECTED OUTPUT
On failure, please mail result to [EMAIL PROTECTED]
200
50
50
50
50
50
50
50
50
50
ACTUAL OUTPUT
On failure, please mail result to [EMAIL PROTECTED]
200
FAILED
003- 50
004- 50
005- 50
006- 50
007- 50
008- 50
009- 50
010- 50
011- 50
/usr/users/nohn/php-4.3.0RC3/ext/standard/tests/math/pow.phpt
EXPECTED OUTPUT
1,1,0,0
On failure, please mail result to [EMAIL PROTECTED]
OK
ACTUAL OUTPUT
1,1,1,1
On failure, please mail result to [EMAIL PROTECTED]
Assert failed:
TRUE === is_infinite(pow(0,-2))
Left: bool(true)
Right: bool(false)
Assert failed:
TRUE === is_infinite(pow(0,-1))
Left: bool(true)
Right: bool(false)
Assert failed:
TRUE === is_infinite(pow(0,-2.0))
Left: bool(true)
Right: bool(false)
Assert failed:
TRUE === is_infinite(pow(0,-1.0))
Left: bool(true)
Right: bool(false)
Re: [PHP-DEV] php.exe - php-cgi.exe
Jan Schneider schrieb: I know this thread is ridden to death but I want to add one argument for completeness: If the cgi's name will be changed, thousands of administrators need to fix their servers. But if the cli's name will be changed thousands of end users of php cli scripts will have to change the scripts' shebang line. I have no idea if there are more administrators who have to care about php cgi or users who use php cli. But at least the first group will have less problems fixing the name change than the latter. PHP-CLI was experimental so far, so anyone who uses it has to be aware of any changes that can happen. PHP-CGI is very far from being experimental. I have no problem with all that renaming thing, but if we rename the CGI-PHP to php-cgi we should do it with php5, because more people will realize that a lot of things change between 4.x and 5.x. For psychological numbering-reasons people don't see any change between 4.2 and 4.3. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Modules/Extensions not in 4.3
Wez Furlong schrieb: o One doc download for the PHP core + bundled extensions (which may reside in PECL). o One doc download for the PEAR classes + non-bundled PECL extensions o One doc download for extension developers (the streams and zend API stuff needs a proper home). o One doc system to rule them all (but keep it modular of course). +1 Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FW: PHP Compile Report
Latest HEAD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 7:19 PM To: [EMAIL PROTECTED] Subject: PHP Compile Report /tmp/work/php4-cvs/ext/mnogosearch/php_mnogo.c: In function `zif_udm_clear_search_limits': /tmp/work/php4-cvs/ext/mnogosearch/php_mnogo.c:1357: warning: unused variable `i' /tmp/work/php4-cvs/ext/mnogosearch/php_mnogo.c: At top level: /tmp/work/php4-cvs/ext/mnogosearch/php_mnogo.c:420: warning: `MyRemoveHiLightDup' defined but not used /tmp/work/php4-cvs/ext/posix/posix.c: In function `zif_posix_getpgid': /tmp/work/php4-cvs/ext/posix/posix.c:459: warning: implicit declaration of function `getpgid' /tmp/work/php4-cvs/ext/posix/posix.c: In function `zif_posix_getsid': /tmp/work/php4-cvs/ext/posix/posix.c:480: warning: implicit declaration of function `getsid' /home/sas/src/php4/ext/standard/url_scanner_ex.re: In function `append_modified_url': /home/sas/src/php4/ext/standard/url_scanner_ex.re:111: warning: unused variable `yyaccept' /home/sas/src/php4/ext/standard/url_scanner_ex.re:113: warning: label `yy10' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:116: warning: label `yy9' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:112: warning: label `yy7' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:111: warning: label `yy5' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:110: warning: label `yy3' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:154: warning: label `yy2' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:147: warning: label `yy1' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re: In function `xx_mainloop': /home/sas/src/php4/ext/standard/url_scanner_ex.re:283: warning: unused variable `yyaccept' /home/sas/src/php4/ext/standard/url_scanner_ex.re:290: warning: unused variable `yyaccept' /home/sas/src/php4/ext/standard/url_scanner_ex.re:300: warning: unused variable `yyaccept' /home/sas/src/php4/ext/standard/url_scanner_ex.re:309: warning: unused variable `yyaccept' /home/sas/src/php4/ext/standard/url_scanner_ex.re:329: warning: label `yy82' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:327: warning: label `yy81' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:343: warning: label `yy78' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:328: warning: label `yy73' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:339: warning: label `yy70' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:326: warning: label `yy65' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:360: warning: label `yy59' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:328: warning: label `yy57' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:326: warning: label `yy56' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:352: warning: label `yy47' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:309: warning: label `yy43' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:345: warning: label `yy39' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:302: warning: label `yy35' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:301: warning: label `yy33' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:299: warning: label `yy29' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:336: warning: label `yy27' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:290: warning: label `yy23' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:326: warning: label `yy19' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:283: warning: label `yy17' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:286: warning: label `yy16' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:282: warning: label `yy14' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:324: warning: label `yy13' defined but not used /home/sas/src/php4/ext/standard/url_scanner_ex.re:319: warning: label `yy12' defined but not used var_unserializer.re: In function `php_var_unserialize': var_unserializer.re:312: warning: comparison is always false due to limited range of data type var_unserializer.re:237: warning: label `yy80' defined but not used var_unserializer.re:280: warning: label `yy79' defined but not used var_unserializer.re:277: warning: label `yy78' defined but not used var_unserializer.re:256: warning: label `yy74' defined but not used var_unserializer.re:263: warning: label `yy72' defined but not used var_unserializer.re:294: warning: label `yy71' defined but not used var_unserializer.re:291: warning:
[PHP-DEV] compiliation of latest cvs fails von cygwin
Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ ext/xml/xml.o(.text+0xad5): In function `zm_info_xml': /tmp/work/php4-cvs/ext/xml/xml.c:233: undefined reference to `__imp__php_XML_ExpatVersion' ext/xml/xml.o(.text+0xdbb): In function `xml_parser_dtor': /tmp/work/php4-cvs/ext/xml/xml.c:297: undefined reference to `__imp__php_XML_ParserFree' ext/xml/xml.o(.text+0x2506): In function `zif_xml_parser_create': /tmp/work/php4-cvs/ext/xml/xml.c:1043: undefined reference to `__imp__php_XML_ParserCreate' ext/xml/xml.o(.text+0x2527):/tmp/work/php4-cvs/ext/xml/xml.c:1047: undefined reference to `__imp__php_XML_SetUserData' ext/xml/xml.o(.text+0x2770): In function `zif_xml_parser_create_ns': /tmp/work/php4-cvs/ext/xml/xml.c:1101: undefined reference to `__imp__php_XML_ParserCreateNS' ext/xml/xml.o(.text+0x2794):/tmp/work/php4-cvs/ext/xml/xml.c:1105: undefined reference to `__imp__php_XML_SetUserData' ext/xml/xml.o(.text+0x2afa): In function `zif_xml_set_element_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1165: undefined reference to `__imp__php_XML_SetElementHandler' ext/xml/xml.o(.text+0x2bc9): In function `zif_xml_set_character_data_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1184: undefined reference to `__imp__php_XML_SetCharacterDataHandler' ext/xml/xml.o(.text+0x2c99): In function `zif_xml_set_processing_instruction_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1203: undefined reference to `__imp__php_XML_SetProcessingInstructionHandler' ext/xml/xml.o(.text+0x2d69): In function `zif_xml_set_default_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1221: undefined reference to `__imp__php_XML_SetDefaultHandler' ext/xml/xml.o(.text+0x2e39): In function `zif_xml_set_unparsed_entity_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1240: undefined reference to `__imp__php_XML_SetUnparsedEntityDeclHandler' ext/xml/xml.o(.text+0x2f09): In function `zif_xml_set_notation_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1258: undefined reference to `__imp__php_XML_SetNotationDeclHandler' ext/xml/xml.o(.text+0x2fd9): In function `zif_xml_set_external_entity_ref_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1276: undefined reference to `__imp__php_XML_SetExternalEntityRefHandler' ext/xml/xml.o(.text+0x30a9): In function `zif_xml_set_start_namespace_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1295: undefined reference to `__imp__php_XML_SetStartNamespaceDeclHandler' ext/xml/xml.o(.text+0x3179): In function `zif_xml_set_end_namespace_decl_handler': /tmp/work/php4-cvs/ext/xml/xml.c:1314: undefined reference to `__imp__php_XML_SetEndNamespaceDeclHandler' ext/xml/xml.o(.text+0x3274): In function `zif_xml_parse': /tmp/work/php4-cvs/ext/xml/xml.c:1342: undefined reference to `__imp__php_XML_Parse' ext/xml/xml.o(.text+0x3495): In function `zif_xml_parse_into_struct': /tmp/work/php4-cvs/ext/xml/xml.c:1377: undefined reference to `__imp__php_XML_SetDefaultHandler' ext/xml/xml.o(.text+0x34b1):/tmp/work/php4-cvs/ext/xml/xml.c:1378: undefined reference to `__imp__php_XML_SetElementHandler' ext/xml/xml.o(.text+0x34c5):/tmp/work/php4-cvs/ext/xml/xml.c:1379: undefined reference to `__imp__php_XML_SetCharacterDataHandler' ext/xml/xml.o(.text+0x34ed):/tmp/work/php4-cvs/ext/xml/xml.c:1381: undefined reference to `__imp__php_XML_Parse' ext/xml/xml.o(.text+0x361a): In function `zif_xml_get_error_code': /tmp/work/php4-cvs/ext/xml/xml.c:1399: undefined reference to `__imp__php_XML_GetErrorCode' ext/xml/xml.o(.text+0x36a7): In function `zif_xml_error_string': /tmp/work/php4-cvs/ext/xml/xml.c:1414: undefined reference to `__imp__php_XML_ErrorString' ext/xml/xml.o(.text+0x37aa): In function `zif_xml_get_current_line_number': /tmp/work/php4-cvs/ext/xml/xml.c:1433: undefined reference to `__imp__php_XML_GetCurrentLineNumber' ext/xml/xml.o(.text+0x383a): In function `zif_xml_get_current_column_number': /tmp/work/php4-cvs/ext/xml/xml.c:1449: undefined reference to `__imp__php_XML_GetCurrentColumnNumber' ext/xml/xml.o(.text+0x38ca): In function `zif_xml_get_current_byte_index': /tmp/work/php4-cvs/ext/xml/xml.c:1465: undefined reference to `__imp__php_XML_GetCurrentByteIndex' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] account update request
could someone please give me (nohn) php4 karma? Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: #19259 [Csd-Ctl]: sort-functions don't work
-Original Message- From: Michael Mauch [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 16, 2002 4:29 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Re: #19259 [Csd-Ctl]: sort-functions don't work I wrote: These test results scared me as well, but it looks like this array test itsself is flawed: it relies on the fact that integers automatically wrap around to negative values at INT_MAX (=2147483647 on 32 bit machines). Attaching a patch for the array test: I changed the array in data.inc to have only normal values (1000 and -1000) instead of 2147483647 and -2147483647, and used the output of the tests on a 32 bit Linux machine to be the expected result. With the patch, all three tests PASSed on the 64 bit Tru64 machine. So array sorting is fortunately not broken again on Tru64. Great! It would be nice if someone with enough karma apply this patch. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test report
http://www.alkoholbedarf.de/kram/test_report_tru64.zip Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Test report
-Original Message- From: Marcus Börger [mailto:marcus.boerger;t-online.de] Sent: Friday, November 15, 2002 3:39 PM To: Sebastian Nohn Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] Test report At 15:17 15.11.2002, Marcus Börger wrote: You need to update again to get exif test fixed. I'll check into getimagesize() Could you try the following patch: I can do it by monday. I see these bugs much more critical: Test arsort, asort, krsort, ksort, rsort, and sort [ext/standard/tests/array/002.phpt] Test usort, uksort and uasort [ext/standard/tests/array/003.phpt] Reporting this on bugs.php.net and marking it as critical Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] 64-bit SGI account offer
-Original Message- From: Seth Price [mailto:sprice;wisc.edu] Sent: Friday, November 01, 2002 2:32 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PHP-QA] 64-bit SGI account offer It sounds like there is a need to get some 64-bit test systems to work with PHP on. Where I work we have some 64-bit SGI systems that we use for various scientific global simulations. I don't use the systems personally, but I spoke with my boss and I may be able to get an ssh login account for someone to get a PHP build working if there is interest. Would you guys find this useful? It think this would be very useful, but I don't have the time to test PHP on just another platform. I even have Problems testing it at my platform, Alpha/Tru64, but I think someone should get an account on that machine. I would suggest someone from the dev-team like Jani or any other bug-hunter rather than someone from the QA-Team for this. Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] #18640: compilation with Oracle fails on Tru64
-Original Message- From: Michael Mauch [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 6:52 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] [PATCH] #18640: compilation with Oracle fails on Tru64 Can somebody please add this? If this is not the right way to send a patch, please tell me. +1 on adding this to cvs. Thies, what's your opinion on this one? Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] array_unique broken?
bugs.php.net seems to be down, so i do it this way: ah. and 4.2.3RC2 and Compaq Tru64 are'nt mentioned on buildtest-submit on qa.php.net When running array_unique over Array ( [0] = 1 [1] = 1 [2] = 1 [3] = 2 [4] = 2 [5] = 3 [6] = 9 [7] = 7 [8] = 4 [9] = 4 [10] = 4 [11] = 4 [12] = 4 [13] = 4 [14] = 4 [15] = 4 [16] = 5 [17] = 12 [18] = 12 ) PHP 4.2.3RC2 on Compaq Tru64 returns Array ( [0] = 1 [3] = 2 [5] = 3 [6] = 9 [7] = 7 [13] = 4 [16] = 5 [18] = 12 ) should'nt it be Array ( [0] = 1 [3] = 2 [5] = 3 [6] = 9 [7] = 7 [8] = 4 [16] = 5 [17] = 12 ) ? Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
-Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:53 PM To: Yasuo Ohgaki Cc: PHP Development Mailing list Subject: Re: [PHP-DEV] mbstring On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 on changing this with PHP 4.x - with PHP 5.x people realize that something big has changed. The register_golabls thing should have also been changed in PHP 5 and not in 4.x, but anyway it's too late for that now ;) Ah. I'm against changing this. But IF it's changed change it with 5. Is --disable-something is too hard to get used to? Yes it is. Why? Because PHP has so many options at this point, finding which modules are automatically enabled isn't terribly easy. More to the point, it's a PITA to find out during the build you forgot to explicitly disable a feature. Well... What about an _optional_ curses based, linux-kernel-like make menuconfig? +--+ | - Extensions | | [x] mySQL| | [x] GD | | .| | .| | .| | [ ] HyperWave | | .| | .| | [x] zlib | || | - Options | | [ ] enable transparent session id | +--+ | Here some description of the option or the | | Extension for examle | || +--+ Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
-Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 6:26 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1 At 12:30 PM 8/19/2002 +0200, you wrote: On Mon, Aug 19, 2002 at 11:45:30AM +0300, Zeev Suraski wrote: How often do you call a function that gives you your current backtrace in C? In my many years of C experience, I would have to say that the accurate answer is -0- times. You really should compare apples with apples... you often said in the past that you don't write php-apps, you write php. i do write php-apps, and debug_backtrace() is one of the most useful features if your app reaches an unexpected failure (= likely a bug). right now i load some zend-extension on my devel boxes - but (as you know), the unexpected often only happens on productions systems. my production systems are soo loaded that i cannot afford to load the zend-extension on there. so post-mortem analysis is much harder there, and you know how hard it sometimes is to reporduce bugs (remember how often i spend hours just to sent you guys the shortest-possible testcase for bugs?) but - in a way you are right, i'm comparing apples and pies. the debug_backtrace() for me is like calling abort() in my c-code to be able to inspect the core-file and see where things went wrong. anyway, i don't thing we are discussing the usefullness of debug_backtrace() here. i think andi will look over the one critical line of the patch - if he agrees that this change is ok, i will go ahead and commit. I still think it shouldn't go in. This is the only feature in Engine 2 which might make non-OOP people convert. Once this isn't in Engine 2 we don't have a carrot for them. Why can't you respect this way of thinking? Especially as I wrote the code? You're basically saying screw them because I'll commit it anyway. I think people using wide-spread OS software will be forced to use ZE2. Take a look at Sebastian Bergmanns openTracker oder the Horde guys. They always use the latest available features of PHP. These are just two examples for OS projects that force people to upgrade their PHP to a recent version. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] strange bug in bugs.php.net
Hi, to reproduce this: - http://bugs.php.net/search.php Select Status: Won't fix, hit Search on the following page select Next 10 Entries Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
-Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 6:58 PM To: Rasmus Lerdorf Cc: Andi Gutmans; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1 with it, but as I said, if this thread at least helped to prevent other stuff from being backported and got people to realize that shifting priorities is right around the corner, then maybe it was worth it). On the one side it like the idea that there is a code-freeze and only bug-fixes are applied to get a version of PHP that works as expected, on the other hand i very much dislike the idea that useful features are held back for political reasons. But a code-freeze will not happen and as youself said, it's impossible to take care for two major releases. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- 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] 4.2.3
-Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 9:20 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 4.2.3 At 10:22 19/08/2002, [EMAIL PROTECTED] wrote: On Mon, 19 Aug 2002, Zeev Suraski wrote: At 10:15 19/08/2002, [EMAIL PROTECTED] wrote: I would actually like to do that once, if you don't mind :) I don't mind at all... but what is the reason for this? :) Well, first it's been a while since I did, but I'd also like to see it working in the 'new way' once, with the automated QA... Since when do we have automated QA? :) To what are you referring here? Well, semi-automatic... Those 'PHP Test Results' letters don't appear to be human generated :) They are. http://qa.php.net/buildtest-submit.php ;) Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bugs.php.net down
traceroute to synacor1.php.net (208.210.50.162), 30 hops max, 40 byte packets [...] 3 pos8-1.hsipaccess1.Frankfurt1.Level3.net (212.162.47.93) 3 ms 3 ms 4 ms 4 unknown.Level3.net (195.122.136.34) 4 ms 4 ms 4 ms 5 so-3-0-0.mp2.London1.Level3.net (212.187.128.57) 18 ms 18 ms 18 ms 6 so-1-0-0.mp2.NewYork1.Level3.net (212.187.128.153) 84 ms 83 ms 83 ms 7 gigabitethernet5-1.core1.NewYork1.Level3.net (64.159.17.101) 84 ms 84 ms 84 ms 8 unknown.inet.qwest.net (209.244.160.130) 84 ms 84 ms 89 ms 9 nycm01-core02.ny.inet.qwest.net (205.171.30.17) 84 ms 85 ms 84 ms 10 nycm01-edge01.ny.inet.qwest.net (205.171.30.86) 84 ms 84 ms 84 ms 11 65.116.172.98 (65.116.172.98) 93 ms 93 ms 93 ms 12 * * * Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP tested on 64-bit OS?
-Original Message- From: Ananth Kesari [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 5:37 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] PHP tested on 64-bit OS? We are working on porting PHP for NetWare. We have a question here: Has PHP been tested on any 64-bit Operating System? I'm running it on Compaq Tru64/Alpha and I'm absolutely not satisfied in how 4.1.x/4.2.x run on that Platform. 4.3-dev runs nice :) On Solaris 7/UltraSparc everything is fine as far as I can see. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 4.2.3
Hi, I'd like to raise the option of releasing 4.2.3 again. I believe that it would be quite a while before 4.3.0 is out, and there are quite a few fixes in the 4.2 branch that should make the userbase as soon as possible, especially the Windows userbase. I think that releasing 4.2.3 can be done within approximately one week, with one RC, barring unexpected surprises. Opinions? As I already said some weeks ago, 4.2.3 would be great if these Bugs were fixed in 4.2.3: http://bugs.php.net/bug.php?id=18639 http://bugs.php.net/bug.php?id=18623 http://bugs.php.net/bug.php?id=18228 http://bugs.php.net/bug.php?id=17449 So, as you can see from this and some other Bugs PHP is on most 64Bit-Platforms buggy as hell. Most things seem to bei fixed in 4.3.0-dev right now and I don't know, how difficult it is to port them back to 4.2 I don't know if http://bugs.php.net/bug.php?id=18640 appears just because I'm dumb or anything (it works with 4.2.0, but I normally don't install PHP on that machine as I'm a programmer not an admin ;)). Maybe Thies knows if I just forgot some exports or options and can close this bug. Here I request again to use my scripts (latest downloadload http://php.nohn.net/autotest/php4-test.1.43.2.tar.gz) for the regression tests as the ones currently in php-qa cvs require to install perl and blablabla. There is still a bug in md5file-testcase (it's the testcase that does'nt work) and it's still dirty coded. See http://php.nohn.net/autotest-stats.php and http://php.nohn.net/autotest-submit.php for how a webpage to this could look like. If you don't like my scripts say it, I don't want to be too much Manuel Lemosish ;) but so far I never got any answer, neither postive nor negative. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 4.2.3
Why release a RC for a software that has some known bugs not fixed. This leads to a RC1, RC2, RC3 and so on. If you only want to fix thw windows bugs you stated, a 4.2.3 would be useless to me, in this case I vote against a 4.2.3 as this would delay 4.3.0 just a little bit more. From: Zeev Suraski [mailto:[EMAIL PROTECTED]] I'd really like to avoid waiting this time, though (the enemy of good is better...). Even if we release 4.2.3 as it is in the branch, without any further fixes, it's significantly better than 4.2.2. Translating this into action - my personal preference is to release the RC as early as tomorrow. Zeev At 16:20 17/08/2002, Dan Kalowsky wrote: Hrm, well a lot of the fixes I've been doing have only gone to head because the belief of no 4.2.3. There are still a few outstanding bugs I'd like to see fixed before things we RC. Sfox and I (mostly her though) have been looking at the dbm_* functionality on Windows. We're questioning if it ever worked at all. I can run through a list if there is a desire to see one. On Sat, 17 Aug 2002, Zeev Suraski wrote: I'd like to raise the option of releasing 4.2.3 again. I believe that it would be quite a while before 4.3.0 is out, and there are quite a few fixes in the 4.2 branch that should make the userbase as soon as possible, especially the Windows userbase. I think that releasing 4.2.3 can be done within approximately one week, with one RC, barring unexpected surprises. Opinions? Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 4.2.3
Hi, At 16:41 17/08/2002, Sebastian Nohn wrote: Why release a RC for a software that has some known bugs not fixed. PHP x.y.z has known bugs that are not fixed, for any given x, y and z, since forever, and until the of time. Realize that, and decisions become much simpler. Releasing a new version makes sense if it's *significantly better* than the previous version. It doesn't have to be perfect. You basically have to weight the gain (the bugs that were fixed, the fact that the semi-major version alternative is likely to be much buggier than a minirelease such as this), versus the price (QA time, possibility of introducing new bugs). If the price appears to be reasonable for the gain, you go for it. Releasing 4.2.3 the way I suggest it will not delay 4.3.0 in any way. Forgive me if I'm wrong, but I don't think anything is happening at all with the 4.3.0 release process anyway. What I'm suggesting is to let users have a significantly better version to use within one week. Nothing more, nothing less. No! This simply confuses users! Someone reported a bug n weeks ago, this bug has been fixed in CVS n-x weeks ago. Now there is a new release an WOW! this bug is'nt fixed! Fixed in CVS means fixed in CVS and the user expects this bug to be fixed in the next release. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3
-Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 17, 2002 10:06 PM To: Sascha Schumann Cc: Xavier Spriet; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PHP-QA] Re: [PHP-DEV] 4.2.3 At 22:58 17/08/2002, Sascha Schumann wrote: 64-bit fixes (for whatever reason), I think that's quite alright. 64-bit support is a major thing, which people, especially businesses, will not really expect to be implemented in a bug-fix release. 64-bit support has worked for years in PHP This is what I thought too. I'm not sure what these fixes are, but it's quite possible that it didn't really work too well in 64-bit systems for years as you and I thought, in which case it's quite alright to wait. I'm not saying we *should* wait, I'm saying it's a possibility, depending on how far-reaching they are. http://bugs.php.net/bug.php?id=18228 did'nt work with 4.2.0. With 4.0.4pl1 everything was fine, did'nt check, when it broke, but if it's needed I can do so. http://bugs.php.net/bug.php?id=18623 did'nt work with 4.2.0. The patch is simple. http://bugs.php.net/bug.php?id=17449 did'nt work with 4.2.0, until 4.1.2, everything was fine. These are the most disturbing bugs in my eyes and for my work. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- 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] 4.2.3
-Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 17, 2002 11:19 PM To: Zeev Suraski Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3 Well, my primary workstation was a 64-bit Alpha system for about a year in 1999 or 2000. After fixing a few issues, PHP worked without a hitch -- while it is easy for me to imagine that new code violated some portability concerns, I don't think that PHP or the Zend engine have been actually destabilized to the effect of being unusable. :-) I've had at a look at the bug reports Sebastian Nohn pointed out. None of these are major issues. Annoying, but nothing which would qualify PHP as being buggy as hell. Still, having these fixes in 4.2.3 would be a definitive advantage. At least all functions of ext/standard should work as expected on all platforms. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Accounts on Alpha/Tru64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm currently trying to get a machine for testing PHP on Tru64/Alpha. Anyone who is _really_ interested in testing AND hunting bugs on that platform should drop me a mail. Regards, Sebastian Nohn - -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBPVukALL8H5XUfVXgEQJ4lgCfdlYHHXIVO+BVhmPn1VJMDJ3Q5FYAn3jh E5nerpDBRG8InaKG+SzNQKQJ =ybdj -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] current warnings on compaq tru64
http://nohn.net/lalafarm/200208140900-error.log Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 0 size snaps?
Sebastian Nohn schrieb: http://snaps.php.net/php4-200207311500.tar.gz http://snaps.php.net/php4-200207311500.tar.bz2 And alle the -latested + the last STABLE Files have 0 size. The snaps are still broken and the last one is still from 07/31/2002 Regards, Sebastian Nohn -- [EMAIL PROTECTED] - http://nohn.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] PHP 4.2.3RC1 ?
Hi, Aren't most of your problems related to using a 64-bit platform? Where were you during QA on 4.2? My sort() stuff works just fine here. On another place in that group where I had very little to do with PHP and if I had to do with it, it was Windows or Linux on x86... Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
-Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 5:13 PM To: Sebastian Nohn Cc: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List; Melvyn Sopacua Subject: Re: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ? Nobody needs 4.3 with 1000 new features, everybody needs a PHP Version that has at least as few bugs as 4.0.4pl1. At least a 4.0.2pl1 fixing the so far closed bugs would be great. I have _SERIOUS_ problems with I would disagree with this statement. PHP 4-CVS currently makes support for MacOSX possible. While I see this being not so important in your This is the first argument for PHP 4.3.0 I can agree with. You're right, I don't need an OS X - Version but I see that it is useful to a lot of people. But regardless, Sebastian your points are all valid on why a 4.2.3 should be made. I think you forget things though like the amount of time each RC I don't _need_ a 4.2.3. I need a bug-free PHP version. 4.3.0 will bring a lot of new features, so everything will start from the beginning again. New features = new bugs. takes, the amount of resources, and the lack of response each one generates. The number of people submitting comments on RCs for 64bit archs is even less. I guess this mostly comes from a not existing click-and-be-happy-System. During 4.1 and 4.2 QA-process there were some test-cases; Everyone had to write tools for these test-cases by himself. I don't think most PHP professionals have the time to do this. Maybe this can be covered by http://nohn.net/lalafarm/php4-test.zip. It not that normale test-thing like run-tests.php, where the developers write their own test-cases (that system will never work). QA-staff or normal users have to write small and easy to understand test-snippets... The end points being these, are your bugs fixed in CVS head? From what I've gathered, yes. Some are, some are not. Can PHP 4.3 be made to be as bug-free as possible? Of course it can be. Yes, with some time and help from all developers. You are welcome to contribute patches to close bugs before the GM is released. I don't think, I have enought knowledge of C to do this. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
-Original Message- From: Xavier Spriet [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 7:09 PM To: Sebastian Nohn Subject: RE: [PHP-QA] RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ? I think focus should be put to making sure the important bugs you are referring to are fixed in the next release of course. However, I am wondering... Which ones of your bug reports are not fixed in CVS or snaps ? http://bugs.php.net/bug.php?id=18623 (reported today, so I don't expect it to be fixed) http://bugs.php.net/bug.php?id=7472 http://bugs.php.net/bug.php?id=16063 http://bugs.php.net/bug.php?id=16068 But I was asking for a release. http://bugs.php.net/bug.php?id=17449 for example was fixed a long time before 4.2.2 it's still not in the release. You are asking for a bug-free version of PHP, yet, you were asking for the release of a PHP 4.2.3 _Release Candidate_ 1 ? Yes! But a release candidate leads to a relase, right? I wanted to test all the bugs affecting me on my platforms. You might also want to consider downgrading your version of PHP since it seems older versions were working fine for you ? Impossible due to features in current PHP Versions I need. I stayed for a very long time on 4.0.4pl1 How is the Quality Assurance team responsible for the fact that administrators are not aware of snaps.php.net ? Did I ever make any accusations? I just wanted to suggest to make a stable version of PHP again but it seems nobody but me needs one... And again: It's not _normal_ to use development versions (it does'nt matter if STABLE or HEAD, everything from snaps.php.net is a development version) because they are more stable. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.2.3RC1 ?
-Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 7:38 PM To: Sebastian Nohn Cc: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List Subject: RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ? On Mon, 29 Jul 2002, Sebastian Nohn wrote: I don't _need_ a 4.2.3. I need a bug-free PHP version. 4.3.0 will bring a lot of new features, so everything will start from the beginning again. New features = new bugs. As I stated earlier, you are welcome to help ensure that this won't be the case. The best thing you can do is become extremely involved in the RC process and testing. I haven't personally experiences many of the problems you claim, but I don't doubt their existance. Yes well... As I already said, I'm on vacation from next week on and my co-workers are only willing and have the time to run some simple and easy to use test-scripts like I wrote. I don't say these scripts are perfect (in fact they may be far away from being perfect) but I think they do enough to use them. The end points being these, are your bugs fixed in CVS head? Some are, some are not. Please make a note of which are not, and try to make them as show-stoppers. That denoatation is ultimately upto the Build-Master, but if we don't know what they are... etc etc you know the rest. The broken array functions are the most disturbing ones. Some are fixed in current cvs but who knows when that changes again ;) For the rest see my last mail. Well... Whatever... The best system would be the one, James suggested: --- cut here --- i would see this working, given it's what we do already. but more specifically, following the apache method of posting patch files when something gets fixed, so people can search the directory and find patches that will fix their problem. See http://www.apache.org/dist/httpd/patches/. --- cut here --- This would allow people to apply only the patches they want and they need and not to install a potentially completly unusable snapshot. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, yes it was, but it was canceled, as Stig, Derick and others agreed, that it would delay 4.3.0 too much. Nobody needs 4.3 with 1000 new features, everybody needs a PHP Version that has at least as few bugs as 4.0.4pl1. At least a 4.0.2pl1 fixing the so far closed bugs would be great. I have _SERIOUS_ problems with theses bugs for example: #17449 #18228 The bugs make it impossible to use my production server (that runs on Tru64/Alpha), so I have to use my development server (that runs on Solaris/Sparc) to run my applications in a productive enviroment. As you can see in the notes to bug #17449 these Bugs apply to various 64bit-platforms like IRIX/Mips, FreeBSD/Alpha, Tru64/Alpha. It think a lot of the other bugs found and fixed in cvs but not in release between 4.2.0 and now cause serious problems to a lot of people who _really_ need these features. These bugs are'nt fixed in 4.2.2, but they were fixed in CVS-2002-07-26. So it should be easy to release this. That - and nobody else has the time to coordinate the effort, while Derick is on vacation. So the plan now is, to start branching and QA 4.3. Strange that people have time for this. Anything revolutionary announced for 4.3.0? Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, has at least as few bugs as 4.0.4pl1. At least a 4.0.2pl1 fixing the so far That is 4.2.2pl1 of course ;) Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, Another option would be to get people to split into 2 teams, and have bug fix team and new feature team, where people specifically look at those features. Make a slightly bigger divide between the two projects. Why not simple delay another buggy release 4.3.0? Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, Because we have no 4.2 release manager with Derick going away. And 4.3 fixes a whole slew of 4.2 bugs And brings 150 new... some of which are not easily backportable to the 4.2 codebase because of the large amount of time between the branches. Yes. That may be. But there are a lot of bugfixes in the latest STABLE-snapshot I tested (26/07/02) - or exactly: All bugs I experienced were fixed. So the easiest thing would be to cancel all new features that were planned for 4.2.3 and move them to 4.3.0 and apply all patches that have been fixed in the last STABLE-snapshot and do a quick release process (no new features, no or at least few new problems). Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, we released 4.2.2 less than a week ago. If we release any new package within 2weeks to a month, i feel it'll just infuriate system admins more. People don't want to be installing new packages every week for the same product. We were running 4.0.4pl1 for more than one year, then we needed some new features and installed 4.1.2, 4.2.0, 4.2.1. No! We did'nt want to install 4.2.0 or 4.2.1 bescause we liked to, or we needed any new feature or our sysadmin wanted to install this, we simple wanted to get a running enviroment. It was pure hell and it is still! These releases were'nt even able to do the most simple things like sorting arrays, creating files directorys, diff'ing arrays and so on. Of all the complaints i hear about PHP, one of the biggest is the frequency of packages; it's too much for people to cope with. People don't have to install new releases every time but they do with PHP. Strange they don't do this with Apache, the Linux kernel or anything else. I don't know WHY people always think the *need* to update PHP, but it's clearly a problem of the admins not of PHP. Maybe it's a problem of PHP, then the only idea I have is that it is caused by bugs, bugs, bugs and people hope their bugs are fixed in the next release. I suggest that if you want fixes, use snapshots or cvs... and we release packages every few months which have been QA tested and are fit for production use. That is _completely_ the wrong way. If I want a stable version of any software I use a release (Linux, Mozilla, Gimp, Win NT 4, MS Office 98, whatever you like). If I want features I take a snapshot (Linux 2.5 for USB 2.0 support, Mozilla for a download manager, Win XP, Office XP, etc.). Currently NO release is fit for production use. Neither does 4.0.4pl1 support today's software nor is it supported by PHP group anymore. It is'nt even downloadable from php.net-Website. Every release older than 4.0.4pl1 is buggy as hell. Does anyone of you expect 4.3.0 to be bug-free? No. Of course I don't expect a 4.2.3 bug free but at least it's a chance to have a release with a very little number of bugs. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, there are not enough people for this. Well. As I already said: Then there are'nt enough people for 4.3.0 too. Yes I know, you are the maintainer of 4.2.x, Stig is the maintainer of 4.3.0. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, Yes. That may be. But there are a lot of bugfixes in the latest STABLE-snapshot I tested (26/07/02) - or exactly: All bugs I experienced were fixed. So the easiest thing would be to cancel all new features that were planned for 4.2.3 and move them to 4.3.0 and apply all patches that have been fixed in the last STABLE-snapshot and do a quick release process (no new features, no or at least few new problems). The use the snapshot for your production box... That is no solution for the real problem. People are frustrated because they don't know if their software runs on the next machine they put it on because this machine maybe has another PHP-version. It's the same thing like GD or Apache 2. Why was GD forked by PHP, why was Apache 2-SAPI development stopped for a long time? Because it was unsatisfying. What does the license say about forking PHP? Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, That is no solution for the real problem. People are frustrated because they don't know if their software runs on the next machine they put it on because this machine maybe has another PHP-version. It's the same thing like GD or Apache 2. Why was GD forked by PHP, why was Apache 2-SAPI development stopped for a long time? Because it was unsatisfying. I meant a 'stable' snapshot which is taken from the PHP_4_2_0 branch. Yes. But a lot of people don't even know that there is a snaps.php.net. Even a lot of admins don't know this. What about calling this snapshot 4.2.3 and releasing this on the homepage? What does the license say about forking PHP? You can fork if you want, but not call it something with PHP in it's name. But consider what you are doing then. What pros does it have instead of using a snapshot? IMO it will only shatter development and QA, and that's not a good idea. I did not say I want to fork PHP ;) I don't even have the knowledge to do this but there are more and more people who want to do something like that and who have the power. I'm working in a big international company and we have a lot of external programmes and consultans, so we have a high fluctuation of high professional programmers (well... most of them are high professional ;)) and some of them have talked about things like this. I think a lot more have thought about this but of course not everyone talked to me on this issue. In the past I always tried to soothe these people by saying the next relase, the next release, the next release... but in the meantime I've stopped to believe in these words. Yes well, that's not your problem but think about this. Another Idea may be a commercially supported PHP with guranteed response times for bugs for professional users who have the money to pay for this. Of course all these patches are managed via PHP CVS and so the normal users get the patches 2-6 months later (if the rely on releases). Maybe this is a concept for companys like Zend or Maguma. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?
Hi, The other major problem is availibilty of platforms QA'd. Sebastian - I trust you'll take the two 64-bit systems you we're talking about? Uh. Yes well... The next week this is no problem, after that I have vacation and I only have access to these machines from my office so I would one check per week or so... I'm not going to stay in office the whole week on my vacation ;) Maybe I can get one or more co-workers of mine doing some tests on our machines - in this case it should be no problem to give daily feedback on workdays. If I think of the mood of my co-workers this is on so far, they _really_ want a running PHP ;) I have an AIX box available, but it doesn't actively run php - it's a DB-backend, so only compilation issues I could track down. I think that for many platforms we don't even have a person let alone two (if there we're 2 QA's to be done). I think more easy, automatically runnable test-cases would be a great thing to get more people do QA-Jobs and to increase the frequency of QA: - people compile PHP with their options - a script is called that does tests for the various extensions (create a picture, save it to disk, md5it ; parse in xml file in an array, diff the result ; parse an xml file with xsl ; query a demo database ; bla ; bla ; bla) - the results incl. OS-string, make, automake, balblabla-version are written into an plain-text or xml-file or are sent to a server (the user should have the option to choose, as the machines i'm working on have no connection to the internet for example) where it is parsed back and written into an easyly queryable database for the qa people. Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php 4.1 can't compile (fwd)
-- Forwarded message -- Date: Sat, 15 Dec 2001 18:13:15 -0500 From: Charlie Romero [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], Charlie Romero [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: php 4.1 can't compile Anyone seeing the same errors I'm seeing? I can't get mnogosearch to compile w/ php 4.1. I'm using mnogosearch 3.2.3. MnoGoSearch compiled fine w/out any errors. Below are the errors from the php make. Any hints??? Charlie make[3]: Entering directory `/usr/local/src/php-4.1.0/ext/mnogosearch' /bin/sh /usr/local/src/php-4.1.0/libtool --silent --mode=compile gcc -I. -I/usr/local/src/php-4.1.0/ext/mnogosearch -I/usr/local/src/php-4.1.0/main -I/usr/local/src/php-4.1.0 -I/usr/local/apache/include -I/usr/local/src/php-4.1.0/Zend -I/usr/local/mnogosearch/include -I/usr/local/mysql/include -I/usr/local/src/php-4.1.0/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -I/usr/local/src/php-4.1.0/TSRM -g -O2 -prefer-pic -c php_mnogo.c php_mnogo.c: In function `zm_startup_mnogosearch': php_mnogo.c:261: `UDM_CACHE_ENABLED' undeclared (first use in this function) php_mnogo.c:261: (Each undeclared identifier is reported only once php_mnogo.c:261: for each function it appears in.) php_mnogo.c:262: `UDM_CACHE_DISABLED' undeclared (first use in this function) php_mnogo.c:296: `UDM_MATCH_WORD' undeclared (first use in this function) php_mnogo.c: In function `zif_udm_set_agent_param': php_mnogo.c:457: `UDM_MATCH_WORD' undeclared (first use in this function) php_mnogo.c:459: warning: unreachable code at beginning of switch statement php_mnogo.c:483: `UDM_CACHE_ENABLED' undeclared (first use in this function) php_mnogo.c:484: structure has no member named `cache_mode' php_mnogo.c:487: `UDM_CACHE_DISABLED' undeclared (first use in this function) php_mnogo.c:488: structure has no member named `cache_mode' php_mnogo.c:485: warning: unreachable code at beginning of switch statement php_mnogo.c:492: structure has no member named `cache_mode' php_mnogo.c:503: structure has no member named `track_mode' php_mnogo.c:503: `UDM_TRACK_QUERIES' undeclared (first use in this function) php_mnogo.c:507: structure has no member named `track_mode' php_mnogo.c:521: structure has no member named `use_phrases' php_mnogo.c:525: structure has no member named `use_phrases' php_mnogo.c:539: structure has no member named `ispell_mode' php_mnogo.c:543: structure has no member named `ispell_mode' php_mnogo.c:555: warning: assignment makes pointer from integer without a cast php_mnogo.c:556: structure has no member named `charset' php_mnogo.c:561: structure has no member named `stop_tables' php_mnogo.c:562: structure has no member named `stop_tables' php_mnogo.c:575: structure has no member named `weight_factor' php_mnogo.c: In function `zif_udm_load_ispell_data': php_mnogo.c:663: structure has no member named `ispell_mode' php_mnogo.c:665: structure has no member named `charset' php_mnogo.c:673: structure has no member named `ispell_mode' php_mnogo.c:676: structure has no member named `ispell_mode' php_mnogo.c:679: too many arguments to function `UdmImportAffixes' php_mnogo.c:687: structure has no member named `ispell_mode' php_mnogo.c:690: structure has no member named `ispell_mode' php_mnogo.c:693: warning: passing arg 4 of `UdmImportDictionary' makes pointer from integer without a cast php_mnogo.c:693: warning: passing arg 5 of `UdmImportDictionary' makes integer from pointer without a cast php_mnogo.c:693: too few arguments to function `UdmImportDictionary' php_mnogo.c:703: structure has no member named `ispell_mode' php_mnogo.c:704: structure has no member named `ispell_mode' php_mnogo.c:706: structure has no member named `spellhost' php_mnogo.c: In function `zif_udm_find': php_mnogo.c:879: structure has no member named `charset' php_mnogo.c:879: warning: passing arg 2 of `UdmFind' makes pointer from integer without a cast php_mnogo.c: In function `zif_udm_cat_list': php_mnogo.c:1164: `UDMSTRSIZ' undeclared (first use in this function) php_mnogo.c: In function `zif_udm_cat_path': php_mnogo.c:1213: `UDMSTRSIZ' undeclared (first use in this function) make[3]: *** [php_mnogo.lo] Error 1 make[3]: Leaving directory `/usr/local/src/php-4.1.0/ext/mnogosearch' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/php-4.1.0/ext/mnogosearch' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/php-4.1.0/ext' make: *** [all-recursive] Error 1 ___ If you want to unsubscribe send unsubscribe general to [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]
