[PHP-DEV] Bug #14750 Updated: exit signal Floating point exception (8)
ID: 14750 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 4.4-RELEASE #0 PHP Version: 4.1.1 New Comment: This works, if it's alone on the page. exit((string)0.1); and this one works too: echo(34); exit(); But this one doesn't: echo(3.5); exit((string)0.1); nor this: echo(22.3); exit(); :-( Previous Comments: [2001-12-29 03:24:05] [EMAIL PROTECTED] Do you have the same problem with a CGI from the command line? Does exit((string)0.1); help you? Feedback. [2001-12-29 00:30:30] [EMAIL PROTECTED] We upgrated to the latest PHP and still getting these errors on ANY php page that uses decimals and EXIT. The shortest sample script, that DOES reproduce the bug: exit(0.1); The following will NOT give error: exit(TEST); Since the PHP upgrade, our problem got worse. Now 8 out of 10 refresh results in The page cannot be displayed Most importantly, the first time the page is hit, it is a 100% error. Please HELP ...---...---...--- /var/log/messages: Dec 6 16:07:17 julian /kernel: pid 38937 (httpd), uid 65534: exited on signal 8 Apache error log: [Thu Dec 6 16:07:17 2001] [notice] child pid 38937 exit signal Floating point exception (8) Original bug: http://bugs.php.net/bug.php?id=14366 Here is some more info. Backtrace data: Program received signal SIGFPE, Arithmetic exception. 0x28162f71 in strtod () from /usr/lib/libc.so.4 (gdb) b Breakpoint 1 at 0x28162f71 (gdb) backtrace #0 0x28162f71 in strtod () from /usr/lib/libc.so.4 #1 0x281ecfec in lex_scan (zendlval=0xbfbfd9d4) at zend_language_scanner.c:4123 #2 0x281ce73c in zendlex (zendlval=0xbfbfd9d0) at zend_compile.c:2344 #3 0x281c5d38 in zendparse () at zend_language_parser.c:1869 #4 0x281eaf61 in compile_file (file_handle=0xbfbff93c, type=2) at zend_language_scanner.c:3036 #5 0x281e2542 in zend_execute_scripts (type=8, file_count=3) at zend.c:749 #6 0x281f3fdc in php_execute_script (primary_file=0xbfbff93c) at main.c:1206 #7 0x281f07d6 in apache_php_module_main (r=0x815b034, display_source_mode=0) at sapi_apache.c:89 #8 0x281f11b6 in send_php (r=0x815b034, display_source_mode=0, filename=0x0) at mod_php4.c:536 #9 0x281f11f2 in send_parsed_php (r=0x815b034) at mod_php4.c:547 #10 0x806b239 in ap_invoke_handler () #11 0x807f940 in process_request_internal () #12 0x807f9aa in ap_process_request () #13 0x8076977 in child_main () #14 0x8076bfc in make_child () #15 0x8076cae in startup_children () #16 0x80772bc in standalone_main () #17 0x8077ad4 in main () #18 0x804ee5d in _start () System: FreeBSD 4.4-RELEASE #0 './configure' '--with-mysql=/usr/local/mysql' '--with-apache=../apache' '--enable-track-vars' '--with-gettext' '--with-imap=../imap' '--with-ldap=/usr/local' Edit this bug report at http://bugs.php.net/?id=14750edit=1 -- 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] References - good or bad
At 08:20 AM 12/29/2001 +0800, Alan Knowles wrote: Andi Gutmans wrote: As I mentioned on the ZE2 mailing list there general rule of thumb is: a) Objects should be passed by reference. b) Everything else including arrays should be used by value whenever possible semantically. In the ZE2 objects will join b). Is there a proposed sytnax to stop copy by reference (Or did i miss it in the ZE2 docs) old stuff $object_copy = $object; //(copy) $object_copy = $object; //(copy reference) new stuff? $object_copy = copy_object($object); //(copy) $object_copy = $object; //(copy reference) To copy around a reference you will just use it as a regular value. Like in your second example, i.e.: $same_object = $object; Basically you're just copying the object handle and not the object itself. In order to create a real copy (with a new object handle) you'll do: $new_object = $object-__clone(); 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] Bug #14750 Updated: exit signal Floating point exception (8)
ID: 14750 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.4-RELEASE #0 PHP Version: 4.1.1 New Comment: And what about CGI (command line)? Previous Comments: [2001-12-29 03:43:52] [EMAIL PROTECTED] This works, if it's alone on the page. exit((string)0.1); and this one works too: echo(34); exit(); But this one doesn't: echo(3.5); exit((string)0.1); nor this: echo(22.3); exit(); :-( [2001-12-29 03:24:05] [EMAIL PROTECTED] Do you have the same problem with a CGI from the command line? Does exit((string)0.1); help you? Feedback. [2001-12-29 00:30:30] [EMAIL PROTECTED] We upgrated to the latest PHP and still getting these errors on ANY php page that uses decimals and EXIT. The shortest sample script, that DOES reproduce the bug: exit(0.1); The following will NOT give error: exit(TEST); Since the PHP upgrade, our problem got worse. Now 8 out of 10 refresh results in The page cannot be displayed Most importantly, the first time the page is hit, it is a 100% error. Please HELP ...---...---...--- /var/log/messages: Dec 6 16:07:17 julian /kernel: pid 38937 (httpd), uid 65534: exited on signal 8 Apache error log: [Thu Dec 6 16:07:17 2001] [notice] child pid 38937 exit signal Floating point exception (8) Original bug: http://bugs.php.net/bug.php?id=14366 Here is some more info. Backtrace data: Program received signal SIGFPE, Arithmetic exception. 0x28162f71 in strtod () from /usr/lib/libc.so.4 (gdb) b Breakpoint 1 at 0x28162f71 (gdb) backtrace #0 0x28162f71 in strtod () from /usr/lib/libc.so.4 #1 0x281ecfec in lex_scan (zendlval=0xbfbfd9d4) at zend_language_scanner.c:4123 #2 0x281ce73c in zendlex (zendlval=0xbfbfd9d0) at zend_compile.c:2344 #3 0x281c5d38 in zendparse () at zend_language_parser.c:1869 #4 0x281eaf61 in compile_file (file_handle=0xbfbff93c, type=2) at zend_language_scanner.c:3036 #5 0x281e2542 in zend_execute_scripts (type=8, file_count=3) at zend.c:749 #6 0x281f3fdc in php_execute_script (primary_file=0xbfbff93c) at main.c:1206 #7 0x281f07d6 in apache_php_module_main (r=0x815b034, display_source_mode=0) at sapi_apache.c:89 #8 0x281f11b6 in send_php (r=0x815b034, display_source_mode=0, filename=0x0) at mod_php4.c:536 #9 0x281f11f2 in send_parsed_php (r=0x815b034) at mod_php4.c:547 #10 0x806b239 in ap_invoke_handler () #11 0x807f940 in process_request_internal () #12 0x807f9aa in ap_process_request () #13 0x8076977 in child_main () #14 0x8076bfc in make_child () #15 0x8076cae in startup_children () #16 0x80772bc in standalone_main () #17 0x8077ad4 in main () #18 0x804ee5d in _start () System: FreeBSD 4.4-RELEASE #0 './configure' '--with-mysql=/usr/local/mysql' '--with-apache=../apache' '--enable-track-vars' '--with-gettext' '--with-imap=../imap' '--with-ldap=/usr/local' Edit this bug report at http://bugs.php.net/?id=14750edit=1 -- 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] Bug #14750 Updated: exit signal Floating point exception (8)
ID: 14750 Updated by: mfischer Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.4-RELEASE #0 PHP Version: 4.1.1 New Comment: No matter what I did, I can't reproduce this. Either with apache 1.3.22 mod_php nor command line version. Please try only with ./configure without any arguments. I think you're systems libs or so are broken. Did you verified you made a clean installation, nor other stale mod_php around? Previous Comments: [2001-12-29 04:14:55] [EMAIL PROTECTED] And what about CGI (command line)? [2001-12-29 03:43:52] [EMAIL PROTECTED] This works, if it's alone on the page. exit((string)0.1); and this one works too: echo(34); exit(); But this one doesn't: echo(3.5); exit((string)0.1); nor this: echo(22.3); exit(); :-( [2001-12-29 03:24:05] [EMAIL PROTECTED] Do you have the same problem with a CGI from the command line? Does exit((string)0.1); help you? Feedback. [2001-12-29 00:30:30] [EMAIL PROTECTED] We upgrated to the latest PHP and still getting these errors on ANY php page that uses decimals and EXIT. The shortest sample script, that DOES reproduce the bug: exit(0.1); The following will NOT give error: exit(TEST); Since the PHP upgrade, our problem got worse. Now 8 out of 10 refresh results in The page cannot be displayed Most importantly, the first time the page is hit, it is a 100% error. Please HELP ...---...---...--- /var/log/messages: Dec 6 16:07:17 julian /kernel: pid 38937 (httpd), uid 65534: exited on signal 8 Apache error log: [Thu Dec 6 16:07:17 2001] [notice] child pid 38937 exit signal Floating point exception (8) Original bug: http://bugs.php.net/bug.php?id=14366 Here is some more info. Backtrace data: Program received signal SIGFPE, Arithmetic exception. 0x28162f71 in strtod () from /usr/lib/libc.so.4 (gdb) b Breakpoint 1 at 0x28162f71 (gdb) backtrace #0 0x28162f71 in strtod () from /usr/lib/libc.so.4 #1 0x281ecfec in lex_scan (zendlval=0xbfbfd9d4) at zend_language_scanner.c:4123 #2 0x281ce73c in zendlex (zendlval=0xbfbfd9d0) at zend_compile.c:2344 #3 0x281c5d38 in zendparse () at zend_language_parser.c:1869 #4 0x281eaf61 in compile_file (file_handle=0xbfbff93c, type=2) at zend_language_scanner.c:3036 #5 0x281e2542 in zend_execute_scripts (type=8, file_count=3) at zend.c:749 #6 0x281f3fdc in php_execute_script (primary_file=0xbfbff93c) at main.c:1206 #7 0x281f07d6 in apache_php_module_main (r=0x815b034, display_source_mode=0) at sapi_apache.c:89 #8 0x281f11b6 in send_php (r=0x815b034, display_source_mode=0, filename=0x0) at mod_php4.c:536 #9 0x281f11f2 in send_parsed_php (r=0x815b034) at mod_php4.c:547 #10 0x806b239 in ap_invoke_handler () #11 0x807f940 in process_request_internal () #12 0x807f9aa in ap_process_request () #13 0x8076977 in child_main () #14 0x8076bfc in make_child () #15 0x8076cae in startup_children () #16 0x80772bc in standalone_main () #17 0x8077ad4 in main () #18 0x804ee5d in _start () System: FreeBSD 4.4-RELEASE #0 './configure' '--with-mysql=/usr/local/mysql' '--with-apache=../apache' '--enable-track-vars' '--with-gettext' '--with-imap=../imap' '--with-ldap=/usr/local' Edit this bug report at http://bugs.php.net/?id=14750edit=1 -- 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] Getting rid of --disable-session configure option.
Sascha Schumann wrote: Problem is in loading *.so file at start up. Session module is designed to provide globals for sub modules, if session module is not compiled in and user load sub module, it spits undefined symbol error at start up. Runtime undefined symbol error for perfectly valid php.ini (or config) is design flaw, IMHO :) That would happen on a platform which does not by default export symbols to the global symbol resolving namespace when loading a shared object. On what platform are you seeing this? Linux if it matters... PHP Warning: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20010901/session_pgsql.so' - /usr/local/lib/php/extensions/debug-non-zts-20010901/session_pgsql.so: undefined symbol: ps_globals in Unknown on line 0 Unknown(0) : Warning - Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20010901/session_pgsql.so' - /usr/local/lib/php/extensions/debug-non-zts-20010901/session_pgsql.so: undefined symbol: ps_globals I've wrote when this could happen sevral times... It does not depend on platform, I suppose. (I don't know about windows) The same senario again. For CGI bin, user tends to disable session. For other SAPI, user tends to include session module. php.ini that work perfect for Web Server SAPI may result in undefined symbol error at CGI bin start up. (i.e. sub module references symbols of parent module) However, session module is internal module and initilized always before normal module, IIRC. It makes external session save handler useless with current session module code :( (We need smart ini parser module loader, also :) We need smart administrators. :) Still, *runtime* undefined symbol error is not smart, isn't it? Design flaw IMHO. We have to do something for it. There are some options and I don't want to hope every users are smart enough that find out runtime undefined symbol error is due to invalid option(s) in php.ini for their build :) Simplest solution is force users to compile sub module with its parents. There are some more options. Stupid one is define all symbols that are required by sub modules. Better one is smart ini parser/module loader. There are others also. BTW, I'm not keep posting about this issue only for session module, but for module dependency issue in general. Happy New Year to all :) See you on list next year! -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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] Bug #14072 Updated: PHP Causes OpenLink Request Broker (odbc_mv.exe) to Segfault upon odbc_do, etc.
ID: 14072 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: ODBC related Operating System: FreeBSD 4.3 PHP Version: 4.0.6 Assigned To: ahill New Comment: No feedback. Closing. Previous Comments: [2001-12-07 12:07:24] [EMAIL PROTECTED] marking as feedback [2001-11-16 10:30:37] [EMAIL PROTECTED] 1. only compile --with-iodbc. Please try this an retest. 2. the reqest broker is oplrqb. the component you report as segfaulting, odbc_mv.exe is the odbc agent - which is it, and how are you determining the windows binary is segfaulting? Either way, please recompile --with-iodbc and test. Best regards, Andrew Hill OpenLink Software [2001-11-15 14:05:58] [EMAIL PROTECTED] (Whoops, I forgot to mention that this is a standard MS Access DSN) Client Platform: Apache 1.3.20/PHP 4.0.6/OpenLink Data Access Drivers (Current as of yesterday), PHP Compiled --with-iodbc --with-openlink Server Platform: WinNT 4.5 SBS, OpenLink Request Broker (Current as of yesterday). When attempting to execute ANY query, ie: select * from table via any method (odbc_do, odbc_exec, odbc_prepare/odbc_execute, etc..) PHP causes a segfault in the Request Broker on the NT machine. This appears to be PHP specific. ./odbctest works fine, and I can establish a connection to my odbc datasource and get any data directly. I have submitted a bug report to OpenLink software as well, but it appears to be PHP specific. Client machine remains running. [2001-11-15 14:03:19] [EMAIL PROTECTED] Client Platform: Apache 1.3.20/PHP 4.0.6/OpenLink Data Access Drivers (Current as of yesterday), PHP Compiled --with-iodbc --with-openlink Server Platform: WinNT 4.5 SBS, OpenLink Request Broker (Current as of yesterday). When attempting to execute ANY query, ie: select * from table via any method (odbc_do, odbc_exec, odbc_prepare/odbc_execute, etc..) PHP causes a segfault in the Request Broker on the NT machine. This appears to be PHP specific. ./odbctest works fine, and I can establish a connection to my odbc datasource and get any data directly. I have submitted a bug report to OpenLink software as well, but it appears to be PHP specific. Client machine remains running. Edit this bug report at http://bugs.php.net/?id=14072edit=1 -- 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] Bug #14751: [critical!] mozilla downloads source of .php files
From: [EMAIL PROTECTED] Operating system: redhat 7.1 glibc2.2.4 kernel2.4 PHP version: 4.1.1 PHP Bug Type: Apache related Bug description: [critical!] mozilla downloads source of .php files I don't exactly understand how this happens, but with a Apache+mod_ssl server, Mozilla 0.9.7 is able to retrieve the source of a .php file, probably by sending non-standard headers. Software used: - Apache 1.3.22 - mod_ssl 2.8.5 - php 4.1.1 - VirtualHost on port 443 with SSLEngine On. - AddHandler application/x-httpd-php .php Test URL: https://secure.mkmgmbh.com/horde/test.php Using Internet Explorer 6, you get the compiled page, using Mozilla 0.9.7 it downloads the source, same url, different behaviour. Please note that the server uses a non-standard certificate (signed by our own CA). [Configure line: './configure' '--prefix=/httpd/php' '--with-apxs=/httpd/bin/apxs' '--with-config-file-path=/httpd/conf' '--with-gdbm=/usr' '--with-mysql=/usr' '--with-openssl=/usr' '--with-vpopmail=/home/vpopmail' '--with-gettext' '--with-xml' '--with-mcrypt=/usr' '--with-imap=/projects/serverupd/imap/imap-2001a' '--with-zlib=/usr'] -- Edit bug report at: http://bugs.php.net/?id=14751edit=1 -- 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] Shootout
In case someone missed it (ok, I just stumbled by accident over it), here's an language shootout (including PHP of course): http://www.bagley.org/~doug/shootout/ -- Please always Cc to me when replying to me on the lists. -- 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] Bug #14751 Updated: [critical!] mozilla downloads source of .php files
ID: 14751 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: redhat 7.1 glibc2.2.4 kernel2.4 PHP Version: 4.1.1 New Comment: seems resolved for us. This phenomenon occurs if the SSL-VirtualHost entry's ServerName differs from the main server's ServerName (in our case nexus.mkmgmbh.com and secure.mkmgmbh.com). Anyway, this is undocumented _and_ leads to strange behaviour (as posted before, IE seems to have no problems, while Mozilla is able to download PHP-Source-Code in this case, which makes this a definite security-risk for all not-thoroughly tested Internet sites!). Jonas Maurus MKM GmbH Previous Comments: [2001-12-29 07:57:26] [EMAIL PROTECTED] I don't exactly understand how this happens, but with a Apache+mod_ssl server, Mozilla 0.9.7 is able to retrieve the source of a .php file, probably by sending non-standard headers. Software used: - Apache 1.3.22 - mod_ssl 2.8.5 - php 4.1.1 - VirtualHost on port 443 with SSLEngine On. - AddHandler application/x-httpd-php .php Test URL: https://secure.mkmgmbh.com/horde/test.php Using Internet Explorer 6, you get the compiled page, using Mozilla 0.9.7 it downloads the source, same url, different behaviour. Please note that the server uses a non-standard certificate (signed by our own CA). [Configure line: './configure' '--prefix=/httpd/php' '--with-apxs=/httpd/bin/apxs' '--with-config-file-path=/httpd/conf' '--with-gdbm=/usr' '--with-mysql=/usr' '--with-openssl=/usr' '--with-vpopmail=/home/vpopmail' '--with-gettext' '--with-xml' '--with-mcrypt=/usr' '--with-imap=/projects/serverupd/imap/imap-2001a' '--with-zlib=/usr'] Edit this bug report at http://bugs.php.net/?id=14751edit=1 -- 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] Bug #14752: missing changelog item
From: [EMAIL PROTECTED] Operating system: N/A PHP version: 4.1.1 PHP Bug Type: Documentation problem Bug description: missing changelog item On the php 4.1.0 changelog page on php.net, there's no mention of the (correctly) fixed return values of strtok(). This is, on the other hand, mentioned in the strtok() documentation page. It wasn't hard to find where the scripts went wrong :) but please add this fix to the changelog as it should also reside there ... -- Edit bug report at: http://bugs.php.net/?id=14752edit=1 -- 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] Bug #14740 Updated: fsockopen() won't timeout
ID: 14740 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Sockets related Operating System: Win98 and Win2k PHP Version: 4.1.0 New Comment: ok to clarify.. seems like this is a common mistake fsockopen() times out ok if the server doesn't exist. The problem occurs when the server doesn't understand what is sent to it afterwards and stalls for a reply (ie, if the port is now used by another service). I'll check the bugs for fwrite(), fgets() etc Previous Comments: [2001-12-28 12:33:49] [EMAIL PROTECTED] A simple query to a server with fsockopen() won't timeout if the requested server is down. $serverquery = fsockopen($host, $port, $errno, $errstr, $timeout); The operation times out first (120 seconds), even if $timeout is as low as 1 second; it works fine if I remove unavailable servers from the query list. Sometimes the server crashes if I try the function again before the last operation times out. [2001-12-28 12:31:36] [EMAIL PROTECTED] A simple query to a server with fsockopen() won't timeout if the requested server is down. $serverquery = fsockopen($host, $port, $errno, $errstr, $timeout); The operation times out first (120 seconds), even if $timeout is as low as 1 second; it works fine if I remove unavailable servers from the query list. Sometimes the server crashes if I try the function again before the last operation times out. Edit this bug report at http://bugs.php.net/?id=14740edit=1 -- 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] Patch regarding 4.0.x - 4.1
Martin Jansen wrote: The following patch changes the version number in the output of phpinfo() from 4.0 to 4. Could anyone with enough karma please commit it or give me the karma to do it myself? Done. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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] Bug #14753: a bug about Ora_pLogon
From: [EMAIL PROTECTED]
Operating system: Win2000AdvServer
PHP version: 4.1.1
PHP Bug Type: Unknown/Other Function
Bug description: a bug about Ora_pLogon
run at pl/sql developer:
/++/
SQL select * from pt_smsojb_temp;
PT_SMSOBJ_TEMP_ID PT_SMSOBJ_TYPE PT_SMSOBJ_ID PT_SMSOBJ_MOBI
PT_SMSOBJ_USER_ID PT_SMSOBJ_NAME
- -- --
-
27 u111390002
1 ³ÂÍ¥êÀ
28 u 113950362526
1 Ò¶½¨±ó
29 o 11390005
1 ´óÍ·
26 u101390001
1 ÁÖÓ¦¹ã
30 o 213959355539
1 Íõ´óÁØ
31 o 313959344539
1 ÍõСÁØ
32 o 41390006
1 ˔Ȼ
33 o 51390007
1 Àî´ó»ª
34 o 61390037
1 ÀîС»ª
35 o 713900030037
1 Àî²»»ª
36 o 813933030037
1 ÀîÁÖ»ª
37 o 91390037
1 ÀîÁÖÁÖ
12 rows selected
/++/
my php code
/++/
html
head
titleÁбí/title
meta http-equiv=Content-Type content=text/html; charset=gb2312
link rel=stylesheet href=../style.css type=text/css
/head
body bgcolor=#FF text=#00 leftmargin=0 topmargin=0
?
$connection=Ora_pLogon(ptsms@doone,ptsms123);
$cursor=Ora_Open($connection);
form name=sendmore method=post action=sendtoobj.php?action=more
target=center_w
?
$query=select * from pt_smsojb_temp;
Ora_Parse($cursor,$query);
Ora_Exec($cursor);
while(Ora_fetch($cursor))
{
?input type=checkbox name=member[] value=?echo
Ora_getcolumn($cursor,0);? checked?echo
Ora_getcolumn($cursor,5);?[?echo Ora_getcolumn($cursor,3);?]br
?
}
?
/form
/body
/html
/++/
It will display 12 records sometimes or 13 records sometimes when I refresh
the web,but it should display 13 records.
Why?
I used the function Ora_commit when I insert a record to database in php.
It's my code.
?
$query=insert into pt_smsojb_temp
(PT_SMSOBJ_TEMP_ID,PT_SMSOBJ_TYPE,PT_SMSOBJ_ID,PT_SMSOBJ_MOBI,PT_SMSOBJ_USER_ID,PT_SMSOBJ_NAME)
values
(pt_smsojb_temp_id.nextval,'u','$PT_SMSOBJ_ID','$PT_SMSOBJ_MOBI','$userid','$PT_SMSOBJ_NAME');
Ora_Parse($curor,$query);
Ora_Exec($curor);
Ora_commit;
?
--
Edit bug report at: http://bugs.php.net/?id=14753edit=1
--
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: Shootout
It should be noted that the shootout reflects rather poorly on PHP. Ranks second to last on the overall scorecard, partly because it is missing some tests. On the tests it does perform on a quick check shows it generally uses significantly more CPU time to do various computations then many of the other languages. Really suprising, but really valuable. For folks doing performance sensitive work it may pay to look at some of the other languages listed or write more c extensions to PHP. Might also be nice to see what can be done to kick PHP's performance up a couple of notches. - August - Original Message - From: Markus Fischer [EMAIL PROTECTED] Newsgroups: php.dev To: [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 5:28 AM Subject: Shootout In case someone missed it (ok, I just stumbled by accident over it), here's an language shootout (including PHP of course): http://www.bagley.org/~doug/shootout/ -- Please always Cc to me when replying to me on the lists. -- 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: Shootout
Can someone run a few of these tests on a machine with --disable-debug. I'd be curious to know how much of a difference that might make. -AZ -- 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: Shootout
This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. Anyways, the challenge is down, here's the code, optimize away. Then we can talk about the real causes for PHP slow performance :) They still may be as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- 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: Shootout
This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. Anyways, the challenge is down, here's the code, optimize away. Then we can talk about the real causes for PHP slow performance :) They still may be as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- 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: Shootout
This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. Anyways, the challenge is down, here's the code, optimize away. Then we can talk about the real causes for PHP slow performance :) They still may be as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- 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: Shootout
Could you specify which $n you were using, and also provide the equivalent Perl script that you used? Zeev On Sat, 29 Dec 2001, August Zajonc wrote: This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. Anyways, the challenge is down, here's the code, optimize away. Then we can talk about the real causes for PHP slow performance :) They still may be as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- Zeev Suraski [EMAIL PROTECTED] 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: Shootout
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted, but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
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] Bug #14754: java.* configuration values from php.ini lost on subsequent executions
From: [EMAIL PROTECTED] Operating system: Windows 2000 SP2 / Apache 1.3.22 PHP version: 4.1.0 PHP Bug Type: Dynamic loading Bug description: java.* configuration values from php.ini lost on subsequent executions This is similar to bug#6990, but since I could no longer append to it, I am opening a new report. The symptoms are the same as descibed in #6990 - on initial execution, all the values from php.ini are imported correctly, including the java.* values so that I can execute custom Java classes from PHP (very cool feature btw). However, after running the page a few times, it gives me the error Fatal error: Unable to create Java Virtual Machine, which most likely means that it has blown up the paths to JDK and classes which I have specified in php.ini, and cannot create a JVM. The trigger which invokes the error seems to be the moment when I change and recompile my Java class. Sometimes it also triggers the error after I update just my PHP code, but not my Java class. Restarting Apache fixes the error each and every time (for a short period - then it occurs exactly the same way), but obviously this is not the viable solution that I am looking for. Bug#6990 also mentions something about placing the [Java] section of php.ini (i.e. configuration for a dynamic module) before or after loading the extension code (in my case, Extension=php_java.dll). This has zero effect - no matter whether the [Java] section is before or after the Extension statement, it behaves exactly the same way. -- Edit bug report at: http://bugs.php.net/?id=14754edit=1 -- 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: Shootout
Taking that code and coupling the Zend Optimizer, PHP and Perl were
approximately the same speed (Perl was 8% faster, but that probably varies
across platforms).
W/o the optimizer PHP was 2 times slower, but again, that's only because
this is not a very real-world piece of code, at least for our space
(scripting languages).
Zeev
On Sat, 29 Dec 2001, August Zajonc wrote:
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted, but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
Zeev Suraski [EMAIL PROTECTED]
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] [IMPORTANT] wishes for php ...
Hi, this one goes out to you Coder! My wishes for the next year are simple and easy to understand - PLEASE DOCCUMENT YOUR CODE! Ask yourself, for who you are coding. You give your sparetime to code things for PHP, and i think you do this, because you will bring it on. Do you really think, that extensions that are not documented bring PHP on the way? How many PHP-Coders do you think will use extensions, when they maybe not even know that they exists (do not say now If you don't know them - you don't need them please ;)) or at least do not know HOW to use them because of missing documentation? I know, that documentation is not the greatest thing on earth to do for programmers, but it is one of the best things to read for users. So please do not blame me and tell me, that it's nice of you to write the extensions, and we should not force you to document. I will not listen to that kind of statements. It is nice, yes, but it does not help PHP, if you do not document it. And i do not think, that every member of the docu-group is able or willing to understand your whole code before documenting it. So please help us and make documentation possible for us. Rasmus himself states out - AFAIK - that PHP is one of the best documented Open Source Project. If he is (still) right, you should really get up and comment your code - so that he stays right. For a list of missing functions see hartmuts function-table. Well, it states 89% documented. But this one does not count for example missing documentation for constants and does not checks the correctness of the documentation (this can happen, if code is changed but know one notice this). And - this is even more important - does seem to count documentated functions, that aren't really documented (i.e. see dio-ext, Mohawk-Software-Session handler functions-ext. and so on) and functions, that are not completely documented (i.e. cURL). Joerg Behrens gave me some ideas, that i will bring to you now. I think they are really worth thinking about. (1) Do not accept any new extensions for php-releases, if it's not documented. fullstop. (2) Please pay attention if you update/change code that is already in the repository. Please do not forget to change protos and to write a line of documentation if necessary. I do not know, if this makes the world a better place, but maybe it makes life easier for people using php ... with best regards, -Wolfgang -- Deutscher PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de Scripte, Tutorials, Installation, Bücher, BestofGML, Manual, Links uvm. PHP 4: Dynamische Webauftritte professionell realisieren: http://php-buch.de -- 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: Shootout
August Zajonc wrote: These are not my tests but Doug's. He compiled default so --debug and --inline-optimization not kicking in. Startup cost also counted, but he tried to run long enough to amortize that. By default, PHP is built without debugging. By the way, what happened to the plan of turning on inline optimization by default? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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] preg_match_all() weirdness
pre
?php
preg_match_all('/\php:([^]]+)\/\/im',
'php:foo var1=value1 var2=value2 /',
$pi
);
print_r($pi);
?
/pre
prints
Array
(
[0] = Array
(
[0] =
)
[1] = Array
(
[0] = foo var1=value1 var2=value2
)
)
I would expect only one array entry...
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
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] preg_match_all() weirdness
Hi,
preg_match_all('/\php:([^]]+)\/\/im',
'php:foo var1=value1 var2=value2 /',
shouldn't this be
[^]+ instead of [^]]+
Kind Regards,
Daniel Lorch
--
if(empty($a) == true ? true : false)
--
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] preg_match_all() weirdness
Hi,
preg_match_all('/\php:([^]]+)\/\/im',
'php:foo var1=value1 var2=value2 /',
shouldn't this be
[^]+ instead of [^]]+
Kind Regards,
Daniel Lorch
--
if(empty($a) == true ? true : false)
--
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] Bug #12223 Updated: ldap rebind procedure implementation
ID: 12223 Updated by: venaas Reported By: [EMAIL PROTECTED] Old Status: Open Status: Analyzed Bug Type: LDAP related Operating System: any PHP Version: 4.0.6 Old Assigned To: Assigned To: venaas New Comment: There is now an experimental implementation. Please test it. It currently requires you to use the OpenLDAP HEAD library. Previous Comments: [2001-07-18 04:21:41] [EMAIL PROTECTED] A ldap rebind procedure for automatical referral chase is not provided in php4. The solution of #9704 doesn't work for ldap_add et al., as these functions do not return a ldap result. This is an inherent problem with synchronous ldap calls. I have written an implementation of ldap_set_rebind_proc registering a php rebind callback. A patch is available on request (or would it be ok to attach a 240-line patch here?). The patch is vs. ext/ldap/ldap.c 1.90 from CVS. Enrik Edit this bug report at http://bugs.php.net/?id=12223edit=1 -- 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] Bug #14754 Updated: java.* configuration values from php.ini lost on subsequent executions
ID: 14754 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Dynamic loading Operating System: Windows 2000 SP2 / Apache 1.3.22 PHP Version: 4.1.0 New Comment: Another note. Users with Linux systems experiencing the same bug reported receiving errors and successes interchangeably - something like 3 errors, 1 success, 3 errors, 1 success etc. This is not true for me - I only keep getting errors until I restart Apache. Previous Comments: [2001-12-29 12:25:14] [EMAIL PROTECTED] This is similar to bug#6990, but since I could no longer append to it, I am opening a new report. The symptoms are the same as descibed in #6990 - on initial execution, all the values from php.ini are imported correctly, including the java.* values so that I can execute custom Java classes from PHP (very cool feature btw). However, after running the page a few times, it gives me the error Fatal error: Unable to create Java Virtual Machine, which most likely means that it has blown up the paths to JDK and classes which I have specified in php.ini, and cannot create a JVM. The trigger which invokes the error seems to be the moment when I change and recompile my Java class. Sometimes it also triggers the error after I update just my PHP code, but not my Java class. Restarting Apache fixes the error each and every time (for a short period - then it occurs exactly the same way), but obviously this is not the viable solution that I am looking for. Bug#6990 also mentions something about placing the [Java] section of php.ini (i.e. configuration for a dynamic module) before or after loading the extension code (in my case, Extension=php_java.dll). This has zero effect - no matter whether the [Java] section is before or after the Extension statement, it behaves exactly the same way. Edit this bug report at http://bugs.php.net/?id=14754edit=1 -- 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: Shootout
Sucks when you need to use a proprietary extension to a language to make
it benchmark well.
George
On Saturday, December 29, 2001, at 12:27 PM, Zeev Suraski wrote:
Taking that code and coupling the Zend Optimizer, PHP and Perl were
approximately the same speed (Perl was 8% faster, but that probably
varies
across platforms).
W/o the optimizer PHP was 2 times slower, but again, that's only because
this is not a very real-world piece of code, at least for our space
(scripting languages).
Zeev
On Sat, 29 Dec 2001, August Zajonc wrote:
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted,
but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
Zeev Suraski [EMAIL PROTECTED]
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 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: Shootout
Interesting... There are a couple of other tests that PHP does poorly on. http://www.bagley.org/~doug/shootout/lang/php/ might be worth looking at. --enable-inline-optimization only made a small difference for me. Generally my results matched up pretty closely with Dougs for the few tests I did on my machine and I didn't catch a lot of unoptimized code. While these are clearly synthetic tests, that looping was similar actually to something I did for a big reference tree of 400,000 odd users that would take up to an hour to complete. Web apps in the end are made up of a bunch of these synthetics. What was suprising to me is that other scripting players like perl did reasonably well on some of them. Java has a more impressive showing than I would I have thought as well. Certainly some interesting food for thought. - August Curious looking forward (ZE2) where PHP is moving performance wise. My sense is that the focus is more feature oriented. - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: August Zajonc [EMAIL PROTECTED] Cc: Sterling Hughes [EMAIL PROTECTED]; Markus Fischer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 9:27 AM Subject: Re: [PHP-DEV] Re: Shootout Taking that code and coupling the Zend Optimizer, PHP and Perl were approximately the same speed (Perl was 8% faster, but that probably varies across platforms). W/o the optimizer PHP was 2 times slower, but again, that's only because this is not a very real-world piece of code, at least for our space (scripting languages). 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: Shootout
Another question, what CFLAGS/CPPFLAGS were used during the compliation of
the test programs for languages that allow compilation? As well as what
cflags were used to compile the intepreters for languages that do not compile
individual programs such as PHP AWK.
In my experience even something as small as lack of -O3 flag can result in a
major performance loss.
Prottoss
[EMAIL PROTECTED]
ICQ: 23361082
http://mediaminer.org/
On December 29, 2001 03:26 pm, August Zajonc wrote:
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted, but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
--
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[2]: [PHP-DEV] Re: Shootout
Hi, $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ these benchmarks aren't significant, anyway. java code will run faster on a native java CPU, so basically it's also architecture-dependant. but nice work, nevertheless! really interesting to see how those languages perform. Kind Regards, Daniel Lorch -- if(empty($a) == true ? true : false) -- 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[2]: [PHP-DEV] Re: Shootout
Hi, Sucks when you need to use a proprietary extension to a language to make it benchmark well. it would be nice to see PHP w and w/o ZEND competing against each other. but I don't think the raw cpu usage can be taken as a indicator for judging a language. there are many other bottlenecks which play a much more important role: database speed, file access latency (whatever you need for storage). absolutely *no* reasonable programmer will ever use PHP to calculate prime numbers or fractals (maybe with mathematical extensions, but not with raw PHP code). face it: PHP is just a layouting engine. it collects data from different sources, gives it the final polish (formatting) and outputs it. nothing more. and YES it's a very feature-rich layouting engine and an excellent one, too. Kind Regards, Daniel Lorch -- if(empty($a) == true ? true : false) -- 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] CVS Account Request: joerg
Contribute to the PHP documentation. Documentate missing functions und translate documentation into german. -- 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] Bug #14755: 105.05$ becomes 105.5$ !!! - I found the fix.
From: [EMAIL PROTECTED]
Operating system: ALL
PHP version: 4.1.1
PHP Bug Type: InterBase related
Bug description: 105.05$ becomes 105.5$ !!! - I found the fix.
Hello. I found a nasty bug in interbase extension, and I
have the solution here. You have only to put it in the
source code; I would but I don't know how to do this. I
already posted the authors, but with no result.
104.05$ become 104.5$ !!!
When traslating scaled numeric fields (i.e. with
decimals), the routine _php_ibase_var_pval is faulty;
here is the original code:
#ifdef SQL_INT64
case SQL_INT64:
val-type = IS_STRING;
val-value.str.len = sprintf(string_data, %Ld.%Ld,
(ISC_INT64) (*((ISC_INT64 *)data) /
(int) pow(10.0, (double) -scale)),
(ISC_INT64) abs((int) (*((ISC_INT64 *)data) %
(int) pow(10.0, (double) -scale;
val-value.str.val = estrdup(string_data);
break;
#endif
You can clearly see that this code is fine if the decimal
part has no 0s before the first non 0 cipher. Here is
my correction:
#ifdef SQL_INT64
case SQL_INT64:
val-type = IS_STRING;
/* Experimental section by Giancarlo Niccolai */
if (scale) {
int i, len;
char dt[20];
double number = (double) ((ISC_INT64)
(*((ISC_INT64 *)data)));
for (i = 0; i -scale; i++)
number /= 10;
sprintf(dt, %%0.%df, -scale);
val-value.str.len = sprintf (string_data, dt ,
number);
}
else {
val-value.str.len = sprintf (string_data, %Ld,
(ISC_INT64) (*((ISC_INT64 *)data)));
}
/* End of experimental section */
val-value.str.val = estrdup(string_data);
break;
#endif
Please, since Interbase is used for e-commerce, all the
php-interbase applications can be at risk, if the site
deals with cents...
--
Edit bug report at: http://bugs.php.net/?id=14755edit=1
--
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] CVS Account Request: mazen
I want to help translating the Manual into german and/or documenting new extensions. -- 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[3]: [PHP-DEV] Re: Shootout
Hi, but I don't think the raw cpu usage can be taken as a indicator for judging a language. there are many other bottlenecks which play a much more important role: database speed, file access latency (whatever you need for storage). just wanted to add something: java is quite successful in commercial applications. not because it's fast, but because you have an excellent ability for code reusage. you can compile java beans into both applets and servlets. people are ready to pay the loss of performance because development time is cut down drastically. development time and code maintenance are much more important than raw performance power nowadays - at least for commercial applications. Kind Regards, Daniel Lorch -- if(empty($a) == true ? true : false) -- 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: CVS Account Request: bradmssw
Brad House [EMAIL PROTECTED] wrote: I have written an extension to php for the MCVE engine. It can be loaded as a module or compiled into the code base, and would like to have it distributed with PHP. I would need commit access in order to maintain the module. The product, MCVE is a credit card processing engine similar in purpose to RedHat's CCVS or CyberCash's ICVerify. Though RedHat's CCVS has been discontinued. And MCVE is the only replacement product for Linux/UNIX systems. would this sort of thing go into pear/PECL or php4/ext these days? (i guess brad wants php4/ext, but i'm looking for other opinions.) jim -- 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: [2]: [PHP-DEV] Re: Shootout
Daniel Lorch wrote: it would be nice to see PHP w and w/o ZEND competing against each other. Zend what? I'd like to see it with/without ZendAccelerator. absolutely *no* reasonable programmer will ever use PHP to calculate prime numbers or fractals (maybe with mathematical extensions, but not with raw PHP code). Perl and the like are used a lot in bio-informatics, and they are scripting-languages. Even in CPU-intensive areas, ease of development can be important. face it: PHP is just a layouting engine. it collects data from different sources, gives it the final polish (formatting) and outputs it. nothing more. and YES it's a very feature-rich layouting engine and an excellent one, too. PHP is a general-purpose language aimed at web-applications. That's more than just layout. A lot more. regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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[2]: [2]: [PHP-DEV] Re: Shootout
Hi, it would be nice to see PHP w and w/o ZEND competing against each other. Zend what? I'd like to see it with/without ZendAccelerator. yes, that's what I meant :) Perl and the like are used a lot in bio-informatics, and they are scripting-languages. Even in CPU-intensive areas, ease of development can be important. but with extensions written in C which do the actual math. correct me, if I'm wrong, but anything else doesn't make sense to me. face it: PHP is just a layouting engine. it collects data from different sources, gives it the final polish (formatting) and outputs it. nothing more. and YES it's a very feature-rich layouting engine and an excellent one, too. PHP is a general-purpose language aimed at web-applications. That's more than just layout. A lot more. it is NOT a general purpose language such as Perl, but it can me (mis-)used for such things. PHP was aimed to enhance webpages. nothing more. Kind Regards, Daniel Lorch -- if(empty($a) == true ? true : false) -- 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] preg_match_all() weirdness
Daniel Lorch wrote: shouldn't this be [^]+ instead of [^]]+ This yields the same result. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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: [3]: [PHP-DEV] Re: Shootout
Daniel Lorch wrote: just wanted to add something: java is quite successful in commercial applications. not because it's fast, but because you have an excellent ability for code reusage. you can compile java beans into both applets and servlets. people are ready to pay the loss of performance because development time is cut down drastically. PHP allows you to produce perfectly reusable code, but it doesn't force you to do that. It doesn't force you to use paradigms that often are just in the way. development time and code maintenance are much more important than raw performance power nowadays - at least for commercial applications. PHP is very good for rapid worse is better style of coding, while being scalable enough to allow somewhat bigger applications. It's a lot prettier than Perl ;-) General purpose may strech it a bit too far, but PHP is suitable for far more than layout. regards Wagner -- Cynic, n.: A blackguard whose faulty vision sees things as they are, not as they ought to be. -- Ambrose Bierce, The Devil's Dictionary -- 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: Shootout
- Original Message - From: Sterling Hughes [EMAIL PROTECTED] The point, if you'd really like to know is that PHP is *not* optimized to do matrix operations (which is one of the examples), or infinitely recursive loops (I'm not even addressing the code at this point) -- but that makes little difference in a real world script. The real world is made up of method calls, array access, counts, echo's, hashes, string concatenation, file i/o. This benchmark tests those. As a side note, If you couple PHP with the Zend Optimizer and/or Zend Cache (or APC Cache for that matter), you'll see PHP start smoking on these examples. Ie, *free* external products can make PHP extremely fast. Does the Zend Cache or APC Cache do things I wasn't aware of? Did you run these examples under these caches and see PHP start smoking? Sterling, generally these products just cache the result of an intermediate compilation step, they do not speed up the actual calls. PHP is a web scripting language first and foremost (although it can be used for other things like cron jobs, or even GUI's). A good benchmark wouldn't match PHP against languages like C, *of course* C will be faster -- there is no way to bring PHP even close to the speed of a *well written* (key phrase) C program. But PHP is also a very easy language to develop with and use, so of course you trade of some speed. It really is stupid to have trivial operations like a large set of cascading loops or matrix multipication. In real life cases is where benchmarks count, and in those cases PHP does a superb job when it comes to performance. A proper benchmark would take into account, RPC, Database access, output capabilities, system accesses, file i/o (sorta-kinda-maybe benchmarked in the test cases, but not properly done.) The matchups I was interested in are not C, that is another red herring you are throwing around. Take a look at perl (a scripting language) which is in this space and which I have actually been talking about. And these trivial operations are trivial for a reason, they allow you to focus in on specific aspects of a languge. When you write your RPC/Database/Output/System/File I/O benchmark good luck figuring out where the problems in any of the languages lie, those types of benchmarks are even more difficult to rely on since a ton of factors can confuse the issue even more. And before you keep on hammering on the fact that that type of benchmark is the one you would see written, take a look at Microsft/Sun/Oracle who benchmark their pet store apps and have no hope of agreeing on anything. Complex apps can be written 30 ways to Sunday, and a small semantic difference can blow results out of the water. The fact is benchmarking is hard, and really stupid trivial can be useful. Anyways, the challenge is down, here's the code, optimize away. Then we can talk about the real causes for PHP slow performance :) They still may be as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. Well: 1) He didn't compile with --enable-inline-optimizations I myelf lean towards these kinds of configuration boo-boo's as a source of problems. --enable-inline does not appear to be one of them. 2) He's not using the Zend Optimizer Propriatery product, not part of php default distro 3) From a base installation perspective, he should be using while loops not for loops (which he does in the Perl example). This does help, but perl still performs 3x faster on my system. 4) he should be using ++$var not $var++ (from a base installation perspective). Makes no appreciable difference. I continue to see these stupid trivial benchmarks as useful. I think that code it in C if you care about performance is a bogus argument, those of us coding real world apps have to occasionaly meet deadlines. Given that, it is nicer to see PHP perform better. Hopefully at the end of this dicussion that may be the case, or at least we'll all be up on how important various compile flags are. - August -- 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: Re[2]: [2]: [PHP-DEV] Re: Shootout
Mmmm :) I suggest you check out php-gtk. People are writing mail clients in PHP (and they are actually *suprisingly* good). The strengths of PHP (and time spent learning it) in one area carry over to others. We'll have to be wondering about misuse when a CS student writes an operating system in PHP. -AZ - Original Message - From: Daniel Lorch [EMAIL PROTECTED] it is NOT a general purpose language such as Perl, but it can me (mis-)used for such things. PHP was aimed to enhance webpages. nothing more. Kind Regards, Daniel Lorch -- if(empty($a) == true ? true : false) -- 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: Re[2]: [PHP-DEV] Re: Shootout
need for storage). absolutely *no* reasonable programmer will ever use PHP to calculate prime numbers or fractals (maybe with mathematical extensions, but not with raw PHP code). Hey I have a little PHP-GTK app that does simple fractals... whats wrong with that??? :P - 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: Shootout
August Zajonc wrote: - Original Message - From: Sterling Hughes [EMAIL PROTECTED] The point, if you'd really like to know is that PHP is *not* optimized to do matrix operations (which is one of the examples), or infinitely recursive loops (I'm not even addressing the code at this point) -- but that makes little difference in a real world script. The real world is made up of method calls, array access, counts, echo's, hashes, string concatenation, file i/o. This benchmark tests those. nobody that knows what is doing will never end up writing such calculus intensive code in PHP! also i want to point you that in some tests, much more related to the usefulness of a scripting language (array hashing and string concats), php performs pretty well, better than java. The real world is also made of web servers, databases, HTML, esoteric API, people learning how to build a program: this kind of benchmark does not take in account this. If this benchmark had some significance everybody will start tomorrow to write web application in that obscure language *mercury*, so strong at nesting loops. regards, -- Roberto Biancardi -- [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: CVS Account Request: bradmssw
I have written an extension to php for the MCVE engine. It can be loaded as a module or compiled into the code base, and would like to have it distributed with PHP. I would need commit access in order to maintain the module. The product, MCVE is a credit card processing engine similar in purpose to RedHat's CCVS or CyberCash's ICVerify. Though RedHat's CCVS has been discontinued. And MCVE is the only replacement product for Linux/UNIX systems. would this sort of thing go into pear/PECL or php4/ext these days? (i guess brad wants php4/ext, but i'm looking for other opinions.) CCVS has been dropped by RH (Perhaps it should be moved to PECL) and I belive MCVE is the replacement. I would personally like to see this in pear/PECL and then perhaps we can work on a generic cc processing extension either in pear in PHP or in PECL written in C. - 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] Bug #14756: pow(0,[broken power]) gives wrong result
From: [EMAIL PROTECTED] Operating system: Linux (Debian 2.2) PHP version: 4.1.1 PHP Bug Type: Math related Bug description: pow(0,[broken power]) gives wrong result The pow() function returns incorrect results when raising zero to a broken power. pow(0,0.5) (the square root of zero), for example, returns NAN. It should return zero. This, is new since 4.0.6. Perhaps it is related to the fix for bug #14544. -- Edit bug report at: http://bugs.php.net/?id=14756edit=1 -- 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] Bug #14757: Apache 1.3.22 can't load the PHP4Apache module
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.1.0
PHP Bug Type: Apache related
Bug description: Apache 1.3.22 can't load the PHP4Apache module
I installed PHP to the default Path and putted in the httpd.conf file
folowed code:
LoadModule php4_module c:/php/sapi/php4apache.dll
AddType application/x-httpd-php .php
When I checked with the test configuration file the code, it issued follow
error:
Syntax error on line 1 of c:/programs/apache group/apache/conf/httpd.conf:
Cannot load c:/php/sapi/php4apache.dll into server: (127) ([{translated}])
Can't find the given procedure.
--
Edit bug report at: http://bugs.php.net/?id=14757edit=1
--
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] Bug #14757 Updated: Apache 1.3.22 can't load the PHP4Apache module
ID: 14757
Updated by: cmk
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Apache related
Operating System: Windows 2000
PHP Version: 4.1.0
New Comment:
Have you copied your php4ts.dll to the %SystemRoot%\system32 directory?
Previous Comments:
[2001-12-29 14:55:44] [EMAIL PROTECTED]
I installed PHP to the default Path and putted in the httpd.conf file folowed code:
LoadModule php4_module c:/php/sapi/php4apache.dll
AddType application/x-httpd-php .php
When I checked with the test configuration file the code, it issued follow error:
Syntax error on line 1 of c:/programs/apache group/apache/conf/httpd.conf: Cannot load
c:/php/sapi/php4apache.dll into server: (127) ([{translated}]) Can't find the given
procedure.
Edit this bug report at http://bugs.php.net/?id=14757edit=1
--
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: is_array_multidimensional
At 09:06 PM 12/29/2001 +, Jim Winstead wrote: Derick Rethans [EMAIL PROTECTED] wrote: Log: - Added extra parameter to count() that recursively counts elements in an array and added is_array_multidimensional(). (patch by Vlad Bosinceanu [EMAIL PROTECTED]) do we really want to perpetuate this idea that a multidimensional array is special in some way? i often get the feeling that people just don't seem to get that what makes an array 'multidimensional' in php is that one array contains other arrays, and things like all the array sorting functions don't somehow treat them differently. I agree with Jim. Arrays can contain things. Things can also be other arrays. You can have an array which contains two other arrays and four integers. I don't think we should add these functions because they are wrong *especially* the is_array_multidimensional(). Of course, if there's a good reason to have them and we're all convinced that the reasons are good we could add them. Can you please roll back that patch and open up a discussion with examples of why this functionality is needed? It might even lead to a different solution. 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] Bug #14747 Updated: Return exitcodes to shell ($?)
ID: 14747 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Suspended Bug Type: Feature/Change Request Old Operating System: Operating System: Windows 2000 with mks-tools Old PHP Version: 4.1.1 PHP Version: 4.0.6 New Comment: Sorry, I just tried your suggestion under Linux and it works. But under Windows2000 with the mks-Toolkit and there it dosn't work. Thnx Bernd Previous Comments: [2001-12-29 15:27:22] [EMAIL PROTECTED] just use exit(number) it returns the exit code (and also prints the value). The printing will be removed in PHP5 (if it is a number). Derick [2001-12-28 16:39:37] [EMAIL PROTECTED] Hi, I tried to use PHP in connection with shellprogramming. I would be fine if you could return exit codes to shellscripts. So that you can use something like if [ $? -eq 0 ] to test if the PHP-Script had run succesful. So wouldn`t need to use Perl in future. Edit this bug report at http://bugs.php.net/?id=14747edit=1 -- 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] Fwd: [Zend Engine 2] Zend Engine 2 Examples
I sent this out to the engine 2 mailing list yesterday. I didn't want to receive too many bug reports at once so I decided to wait a day before I send it to php-dev (although most of you are probably on that list too). Please try and mess around with it. An example script of features is attached or can be downloaded from http://www.php.net/~andi/zend2.zip Please don't announce it anywhere else because I don't think it's ready for a wider audience. Andi Date: Fri, 28 Dec 2001 07:35:22 +0200 To: [EMAIL PROTECTED] From: Andi Gutmans [EMAIL PROTECTED] Subject: [Zend Engine 2] Zend Engine 2 Examples Hey, I'm attaching a script which tries to give short examples for most of the new object stuff in the Zend Engine 2. I think the Zend Engine 2 is at the stage where people can start playing around with it and in my opinion from looking over the examples script the new changes are really cool and allow for some much nicer development. There are some small quirks I know about, but in any case, let me know of any you find. I think this is a good time for people to start playing around with it. Just check out the ZendEngine2 CVS (instead of the Zend CVS) and rename it to Zend before doing ./buildconf and ./configure. A special note on destructors: I am still not sure how well they will work because it's not obvious that PHP will always be in a stable enough state to run them but I guess that's the same issue you'd have in C++ after a segfault. So this change really needs a lot of testing and we need to see when and when not destructors can work. Please play around a bit with the Zend Engine. I'm also interested in hearing how many changes you actually had to make to your scripts due to the fact that objects are now handles (i.e. how many scripts this actually broke). A big thanks to Stig who helped iron out the whole idea of nested classes and how we make them functional so that they can be used as namespaces for projects such as PEAR. I'm aware that I didn't explain the samples and some things aren't in the Zend Engine 2 document (especially the whole nested classes stuff) so if you have any questions, ask. Enjoy :) Andi zend2.php Description: Binary data -- 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] Bug #14757 Updated: Apache 1.3.22 can't load the PHP4Apache module
ID: 14757
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Apache related
Operating System: Windows 2000
PHP Version: 4.1.0
New Comment:
Yeah I have found the problem. I've fergotten to copy the zip-package.
thx for help.
PS: I can't close this bug report because I've fergotten the password too. :(
Previous Comments:
[2001-12-29 15:23:14] [EMAIL PROTECTED]
Have you copied your php4ts.dll to the %SystemRoot%\system32 directory?
[2001-12-29 14:55:44] [EMAIL PROTECTED]
I installed PHP to the default Path and putted in the httpd.conf file folowed code:
LoadModule php4_module c:/php/sapi/php4apache.dll
AddType application/x-httpd-php .php
When I checked with the test configuration file the code, it issued follow error:
Syntax error on line 1 of c:/programs/apache group/apache/conf/httpd.conf: Cannot load
c:/php/sapi/php4apache.dll into server: (127) ([{translated}]) Can't find the given
procedure.
Edit this bug report at http://bugs.php.net/?id=14757edit=1
--
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] Bug #14757 Updated: Apache 1.3.22 can't load the PHP4Apache module
ID: 14757
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Bogus
Bug Type: Apache related
Operating System: Windows 2000
PHP Version: 4.1.0
New Comment:
It's bogus anyway.
Previous Comments:
[2001-12-29 16:33:28] [EMAIL PROTECTED]
Yeah I have found the problem. I've fergotten to copy the zip-package.
thx for help.
PS: I can't close this bug report because I've fergotten the password too. :(
[2001-12-29 15:23:14] [EMAIL PROTECTED]
Have you copied your php4ts.dll to the %SystemRoot%\system32 directory?
[2001-12-29 14:55:44] [EMAIL PROTECTED]
I installed PHP to the default Path and putted in the httpd.conf file folowed code:
LoadModule php4_module c:/php/sapi/php4apache.dll
AddType application/x-httpd-php .php
When I checked with the test configuration file the code, it issued follow error:
Syntax error on line 1 of c:/programs/apache group/apache/conf/httpd.conf: Cannot load
c:/php/sapi/php4apache.dll into server: (127) ([{translated}]) Can't find the given
procedure.
Edit this bug report at http://bugs.php.net/?id=14757edit=1
--
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: is_array_multidimensional
On Sat, Dec 29, 2001 at 11:13:11PM +0200, Andi Gutmans wrote: I agree with Jim. Arrays can contain things. Things can also be other arrays. You can have an array which contains two other arrays and four integers. I don't think we should add these functions because they are wrong *especially* the is_array_multidimensional(). Agree Of course, if there's a good reason to have them and we're all convinced that the reasons are good we could add them. Can you please roll back that patch and open up a discussion with examples of why this functionality is needed? It might even lead to a different solution. One solution (not so sure I like it myself), could be a function that tells whether an array contains values of a given type. Then you could check if the array contained an array (or any other type). I've never had a use for such myself. Stig -- 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: is_array_multidimensional
At 10:42 PM 12/29/2001 +0100, Stig Venaas wrote: On Sat, Dec 29, 2001 at 11:13:11PM +0200, Andi Gutmans wrote: I agree with Jim. Arrays can contain things. Things can also be other arrays. You can have an array which contains two other arrays and four integers. I don't think we should add these functions because they are wrong *especially* the is_array_multidimensional(). Agree Of course, if there's a good reason to have them and we're all convinced that the reasons are good we could add them. Can you please roll back that patch and open up a discussion with examples of why this functionality is needed? It might even lead to a different solution. One solution (not so sure I like it myself), could be a function that tells whether an array contains values of a given type. Then you could check if the array contained an array (or any other type). I've never had a use for such myself. Let's first try and understand the problem :) In what case does the user need these functions and how often does this happen to people. Once we understand the problem well we can think together of a good solution. 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-DOC] Re: [PHP-DEV] [IMPORTANT] wishes for php ...
From: Markus Fischer [EMAIL PROTECTED] Ah, and btw, that's what we've the documentation team for, no? If we get no information there will be no documentation. I see the faqt, that extension authors aren´t able or will not write correct prototype folding hooks. Please read yourself CODING_STANDARDS. -Egon -- 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-DOC] Re: [PHP-DEV] [IMPORTANT] wishes for php ...
On Sat, Dec 29, 2001 at 10:43:32PM +0100, Egon Schmid wrote : From: Markus Fischer [EMAIL PROTECTED] Ah, and btw, that's what we've the documentation team for, no? If we get no information there will be no documentation. I see the faqt, that extension authors aren´t able or will not write correct prototype folding hooks. Please read yourself CODING_STANDARDS. Thanks, Egon , I know them. Point them to someone else. -- Please always Cc to me when replying to me on the lists. -- 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: Shootout
August Zajonc continues with ... I continue to see these stupid trivial benchmarks as useful. The benchmark code is pre-alpha and incomplete as the author states expressly. 'Useful' does not imply reliable, factual, or scientific. In my view, what I've seen and read is neither useful, nor harbours any of the other qualities, mentioned above, that reasonable people might consider important. IMHO, the benchmarks are bogus from the get go, and this discussion is moot. Hopefully at the end of this dicussion that may be the case, or at least we'll all be up on how important various compile flags are. Please ask support questions on the friendly helpful php-general list. Mike Robinson -- 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: Shootout
At 00:11 30/12/2001, August Zajonc wrote: Does the Zend Cache or APC Cache do things I wasn't aware of? Did you run these examples under these caches and see PHP start smoking? Sterling, generally these products just cache the result of an intermediate compilation step, they do not speed up the actual calls. If you use caching software, chances are PHP will be faster than Perl even without the optimizer. And it does that without any hassle or special planning, unlike Perl for that matter. If you use the optimizer - it gets as quick as Perl, and that's without caching. Couple the two together - and you have a serious performance screamer. That said, in most real world situations, PHP will be faster than Perl even w/o these two. I don't agree that Web apps are just made of small snippets like this. In Web apps - database performance, output handling and caching play a big role, which these code snippets don't measure. FWIW, I agree with you that 'code in C if you need performance' is quite a pointless statement, except for very specialized cases. One of the main points in using PHP is *not* using C, because of dev-time, maintenance, reliability, etc. etc. 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-DOC] Re: [PHP-DEV] [IMPORTANT] wishes for php ...
Ok, we will start off with removing ext/socket and ext/domxml. Their manuel pages have been adapted with the function calls by Hartmut (thx!) but yet they aren't really documented. Gread idea, no? You should read my mail carefully before getting funny. What i wrote Do not accept any new extensions for php-releases ... Two things in one sentence you didn't read or didn't care about. And, alas you said you don't listen to this answer: You can't force anyone to do anything. OpenSource, that is. And, a guide role 'not to commit without documentation' .. hehe, doesn't sound feasible. see above. Read my mail. Ah, and btw, that's what we've the documentation team for, no? I think you should hold your breath. You do not really believe what you wrote, do you? I think documentation-people have better things to do, then reading and trying to understand code which has not one line of comment nor documentation. Oh: Hey it's OpenSource - we do what we want! pfff. Is this lala-land? -Wolfgang -- Deutscher PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de Scripte, Tutorials, Installation, Bucher, BestofGML, Manual, Links uvm. PHP 4: Dynamische Webauftritte professionell realisieren: http://php-buch.de -- 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: is_array_multidimensional
Andi Gutmans wrote: At 10:42 PM 12/29/2001 +0100, Stig Venaas wrote: On Sat, Dec 29, 2001 at 11:13:11PM +0200, Andi Gutmans wrote: I agree with Jim. Arrays can contain things. Things can also be other arrays. You can have an array which contains two other arrays and four integers. I don't think we should add these functions because they are wrong *especially* the is_array_multidimensional(). Agree Of course, if there's a good reason to have them and we're all convinced that the reasons are good we could add them. Can you please roll back that patch and open up a discussion with examples of why this functionality is needed? It might even lead to a different solution. One solution (not so sure I like it myself), could be a function that tells whether an array contains values of a given type. Then you could check if the array contained an array (or any other type). I've never had a use for such myself. Let's first try and understand the problem :) In what case does the user need these functions and how often does this happen to people. Once we understand the problem well we can think together of a good solution. Andi Oh well... I tried to find a use for it, but failed :(. I wrote it for no reason, thinking it would be useful to someone, somewhere... So i guess i agree with all of you (more or less). -- 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] [IMPORTANT] wishes for php ...
Obviously, you shouldn't have taken this mail too seriously. Did you!? ;-) On Sat, Dec 29, 2001 at 11:17:11PM +0100, Wolfgang Drews wrote : Ok, we will start off with removing ext/socket and ext/domxml. Their manuel pages have been adapted with the function calls by Hartmut (thx!) but yet they aren't really documented. Gread idea, no? You should read my mail carefully before getting funny. What i wrote Do not accept any new extensions for php-releases ... Two things in one sentence you didn't read or didn't care about. And, alas you said you don't listen to this answer: You can't force anyone to do anything. OpenSource, that is. And, a guide role 'not to commit without documentation' .. hehe, doesn't sound feasible. see above. Read my mail. Ah, and btw, that's what we've the documentation team for, no? I think you should hold your breath. You do not really believe what you wrote, do you? I think documentation-people have better things to do, then reading and trying to understand code which has not one line of comment nor documentation. Oh: Hey it's OpenSource - we do what we want! pfff. Is this lala-land? -Wolfgang -- Deutscher PHP-Knotenpunkt Dynamic Web Pages: http://www.dynamicwebpages.de Scripte, Tutorials, Installation, Bucher, BestofGML, Manual, Links uvm. PHP 4: Dynamische Webauftritte professionell realisieren: http://php-buch.de -- Please always Cc to me when replying to me on the lists. -- 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: Shootout
Mike, I would suggest you look at the totally bogus mindcraft benchmarks of linux/apache. Those were orders of magnitude more bogus than anything here, yet ended up being useful. Further, many posters seem to confuse a discussion of PHP's performance with a dicusion of its quality as a language overall. That is a mistake. People need to realize that these benchmarks test one narrow aspect of PHP, and are not a ranking of its quality as a language. There is an important difference there. Mike Robinson: The benchmark code is pre-alpha and incomplete as the author states expressly. 'Useful' does not imply reliable, factual, or scientific. In my view, what I've seen and read is neither useful, nor harbours any of the other qualities, mentioned above, that reasonable people might consider important. IMHO, the benchmarks are bogus from the get go, and this discussion is moot.the benchmarks are bogus from the get go, and this discussion is moot. I have yet to see anything approching the care and completness of this guys benchmarks, pre-alpha and bogus or not with respect to PHP vis a vis other languages. In contrast to plenty of others they are open about their flaws, fully describe methadology and allow others to repeat them. Frankly, they seem to do a good job of testing what they set out to test, nested loops, array indexing and so on. aka they are as reliable, factual, and scientific as anything else I have seen put out. The open source community loves to critize, but I see few of these theoretical real world benchmarks floating around. I'm frankly surprised at some of the strong reactions to these benchmarks... think I'm going to get back to work :) - August -- 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: Shootout
- Original Message - From: Zeev Suraski [EMAIL PROTECTED] If you use caching software, chances are PHP will be faster than Perl even without the optimizer. Interestingly, Perl is getting bytecode caching soon, RFC 301 I think. Probably about time. And it does that without any hassle or special planning, unlike Perl for that matter. If you use the optimizer - it gets as quick as Perl, and that's without caching. Couple the two together - and you have a serious performance screamer. Yes, we have succesfully used PHP on a site getting 6 million hits a day. Granted we wished we could have used fewer servers, but with caching and proper design things can go pretty high. Performance wise I'd bet that 60%+ of folks are not getting even some of the obvious huge performance wins (static compile, cache + optimizer, reverse proxy in front if lots of slow connections, proper configuration and on and on and on). That said, in most real world situations, PHP will be faster than Perl even w/o these two. I don't agree that Web apps are just made of small snippets like this. In Web apps - database performance, output handling and caching play a big role, which these code snippets don't measure. Couldn't agree more. But of course if one language in a similar space can get blazing speed in a little code snippet it's always nice to see if something can be tweaked to improve things in your favorite language. FWIW, I agree with you that 'code in C if you need performance' is quite a pointless statement, except for very specialized cases. One of the main points in using PHP is *not* using C, because of dev-time, maintenance, reliability, etc. etc. Yes, dev time, good docs, maintenence, reliabity outweigh performance concerns 90% of the time, and hardware is only getting cheaper. PHP's biggest wins are in some of those areas. What gets people riled up about these benchmarks is they see them as a whole picture slam against their favorite language, even if the benchmark is pretty clear about testing something pretty narrow which I think these are, they are remarkably honest for a benchmark. - August -- 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: Shootout
At 04:07 30/12/2001, August Zajonc wrote: - Original Message - From: Zeev Suraski [EMAIL PROTECTED] If you use caching software, chances are PHP will be faster than Perl even without the optimizer. Interestingly, Perl is getting bytecode caching soon, RFC 301 I think. Probably about time. That RFC is from over a year ago, what makes you think it's going to happen soon..? It still remains to be seen if they do it in a nice, clean transparent way, or the Perl way :) Anyway, the other problems plaguing Perl still apply (having to worry about resourcesmemory). What gets people riled up about these benchmarks is they see them as a whole picture slam against their favorite language, even if the benchmark is pretty clear about testing something pretty narrow which I think these are, they are remarkably honest for a benchmark. Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. 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: Shootout
- Original Message - From: Sterling Hughes [EMAIL PROTECTED] Manuel, (I get all the trolls confused, one name makes it easier) These trolls happen to use PHP on a daily basis, and have for years. Always good to see the name calling start early :) Thanks! I wasn't aware of how they work, this clears everything up... Read: The Zend *Optimizer* and the Zend or APC Cache. When the scripts get larger this *does* help, especially when dealing with many requests. I was simply pointing out that the cache is unlikely to improve these benchmarks. The loading/interpretation step is short relative to a long benchmark run and this guy running them actually worked to factor out the startup time. This is not 1000 web requests where the cache makes a night and day difference, but a single request with a very long running time. The fact is benchmarking is hard, and really stupid trivial can be useful. No -- they can't. This is the whole point, benchmarks must be specific and must be applied to your current application/architecture/task. The fact is, the things this code is benchmarking are not only subject to the implementation of one person, but they are also so limited in scope, function, quality (of code), that they are flat out misleading. It seems to me that these small benchmarks are more specific then your full app benchmark. They are LESS subject to personal implementation difference since they are so simple. And I don't see where they are that misleading, they test what they say (array indexing) and are CLEAR about the limits of their scope and function, and I'm assuming folks on -dev realize that web apps are not long running highly nested for() loops. 2) He's not using the Zend Optimizer Propriatery product, not part of php default distro So? Anybody worth their salt as a programmer would consider the Zend Optimizer if they needed to speed up their production website. Not if they can't afford the (old) Zend Accelerator pricing and it didn't have a trial option and are using a free alternative which is incompatabile with the Optimizer. Anyone in the real world also has to make budget decisions, and we compared the win from the optimizer with that of the cache for OUR applications and made a decision. Does that mean I and others are not worth are salt as programmers? Hardly, that is rediculously narrow sighted. - August -- 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: Shootout
- Original Message - From: Zeev Suraski [EMAIL PROTECTED] That RFC is from over a year ago, what makes you think it's going to happen soon..? It still remains to be seen if they do it in a nice, clean transparent way, or the Perl way :) Anyway, the other problems plaguing Perl still apply (having to worry about resourcesmemory). Since I dislike programming in perl I'm probably not the best to comment on the line noise... ^H^H code that perl generates. Nor the delay from their RFC's on bytecoding. Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. I agree. Was following up on an earlier post, had read through the benchmark carefully and he's got disclaimers everywhere, plus this is -dev, where one would imagine folks have a better grasp on the gap between performance benchmarking and the real world, much less language qualities as a whole... I've learned my lesson, this can suck up a good number of hours... - August -- 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] Bug #14538 Updated: dirname fix brokebehaviourthat it had since PHP 3
Hello, I thought that this thread was over. Anyway, I finally made time to ban the functions that you broke from my site code. Since it gave me a lot of work and I feel that others could also benefit of the workarounds functions that I had to develop, I have just released a a class and some wrapper functions that provide the original behaviour of the broken functions. The class is available here: http://phpclasses.UpperDesign.com/browse.html/package/404 . Downloading the class code does not require you to be subscribed. Later I will make a more complete announcement for those that are not subscribed to the PHP Classes Repository site. Zeev Suraski wrote: At 03:43 16/12/2001, Manuel Lemos wrote: So, there why keep giving more reasons to not upgrade? Because sometimes it's necessary. The way dirname() behaved was buggy and unintended - it simply did not do what it was supposed to do. Perhaps Yes, but people where relying on the original behaviour. For instance, if you have a reloctable script and want to figure a sub-directory where you may have the graphic image files, you would use something like dirname(GetEnv(SCRIPT_NAME))./graphics/icon.gif. This stopped working when you broke dirname because if GetEnv(SCRIPT_NAME) is for instance /index.php, dirname now returns / while before it returned , so the expression above becomes //graphics/icon.gif . dirname never returned a path ending with / and that extra slash makes browsers not download the graphic image files as always breaking the behaviour of a site that is up and running for more than 2 years. taking it to the extreme - it's kind of like pow(2,2) returning 4.01 instead of 4. If such a bug existed in pow() and we fixed it, we wouldn't have added an ini switch to turn it on/off. Except that I doubt that anybody would be relying in the behaviour because floating point math is not supposed to be accurate. BTW, I don't know if you are aware but arbitrary precision math functions are useless because it applies to the arguments the number of the decimal places that it should be applying only to results. There is a long standing bug rotten in the bug database waiting for somebody to fix it. You could fix such kinds of bugs to make arbitrary precision extension of any use instead of breaking the behaviour of functions that work as they did for 4 years. register_globals is completely different. register_globals is a concept which turned out to be very problematic, but people who bought into it It is always problematic. The difference is that you only realized recently, just like the behaviour of dirname and strtok that you broken. should be allowed to go on using it. We also have to be a bit realistic every now and then, and realize that the vast majority of PHP code today, and we're talking dozens of millions of lines of code, relies on register_globals being on. That's not true for dirname(). It doesn't mean Says who? Have you counted the number of people that are using dirname or strtok. that BC breaks that only affect a small number of people should be taken lightly - but obviously, this plays a significant role. Yeah, that is the same unrespectful conclusion as Rasmus, it is just Manuel complaining. Admit it, you were not aware and not even documented the change that Andi made to the behaviour of a function that worked like that for 3 years. Sure but they way it seems to me is that reporting the problem did not make any difference. So why bother reporting? It's your decision. Don't expect the dev-team to treat anything you put in the bugs database as the 11th commandment. The dirname() example is relatively unique, because the new behavior is not a problem, but a fixed behavior which causes incompatibility. Incompatibility with what? Of something that never relied on it because the function never behaved before like the way it behaves when you fixed it? And what about strtok that was broken in November? What incompatibility it causes to whose PHP software? I am afraid that a lot of people simply do not bother to report problems, even when it affects their businesses, because they just get this kind of response and they certainly can use the time they spend making a useful report in things that can really result in something that the need. Don't worry so much. You're the first person to bring up this point in 5 years :) Because most people don't know yet, as you broke the behaviour of two functions silently and did not document it anywhere! Also, when people will be aware, they as well not bother to tell you, especially if they know you track record of overuling people reports, even when they are made with consistent argumentation. Anyway, I really sorry for you because you have lately shown a very inconsistent attitude towards people that have invested a lot to help you on PHP/Zend development. While in Zend 2 list you have fought very hard people overuling their proposals to
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] [IMPORTANT] wishes for php ...
From: Markus Fischer [EMAIL PROTECTED] Obviously, you shouldn't have taken this mail too seriously. Did you!? ;-) We expect on serious postings only serious responses. The best thing we can do is to do nothing. -Egon -- 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: Shootout
So? Anybody worth their salt as a programmer would consider the Zend Optimizer if they needed to speed up their production website. Not if they can't afford the (old) Zend Accelerator pricing and it didn't have a trial option and are using a free alternative which is incompatabile with the Optimizer. Another nasty-nasty about the optimizer is that it prevents any non-Zend zend_extensions from being loaded with it. The Zend Optimizer limits (my) options, not increases them, which I think what August is getting at. -- 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: Shootout
Zeev Suraski writes: Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. You betcha, wrong ideas I was about to activate the Omega-13. ;) Regards Mike Robinson -- 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: Shootout
I have to say that taking a look at his site again - he does have disclaimers. Even though none is as strong as 'This may have nothing to do with reality', it's not that bad... At 01:49 30/12/2001, Mike Robinson wrote: Zeev Suraski writes: Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. You betcha, wrong ideas I was about to activate the Omega-13. ;) Regards Mike Robinson -- 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: Shootout
Just to be clear I'll list a few for the record. He's got them there to avoid the flames and claims of unfair. - All artificial language performance benchmarks, mine included, *do not measure real-world performance*. One should not choose a language based only on its benchmark ranking, even if you believe the benchmark to be fair. In an ideal world, we would choose the language that makes us most productive, and which can be optimized fairly easily, when that optimization is needed. That means a good language will include a profiler tool to allow you to measure which parts of your application are slow, so you can rewrite those parts to be faster. Many scripting languages allow you to rewrite the slow parts in C, which should be just about all you need for speed. Of course, a badly designed application may be difficult to profile and speed up. But that's the fault of the programmer, not the language. And another - Some languages are not tested on their strengths, but mostly on their weaknesses. Case in point: PHP. PHP is a fine web scripting language that provides a multitude of built-in convenience functions to simplify writing code for common CGI tasks. Since this shootout is a basic language test, and I don't have or plan to have any CGI scripting tests, the fact that PHP is somewhat slower in my tests than other scripting languages is hardly an argument against its use as a web scripting language. - You should keep in mind that you may get significantly different results on a different platform. http://www.bagley.org/~doug/shootout/method.shtml#flaws for a long list, then read disclaimer then read faq I think and by then you'll have read more disclaimers then folks ranting here have thought of or had time to say. Hopefully this will avoid the Omega-13 :) - August - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: August Zajonc [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 3:51 PM Subject: RE: [PHP-DEV] Re: Shootout I have to say that taking a look at his site again - he does have disclaimers. Even though none is as strong as 'This may have nothing to do with reality', it's not that bad... At 01:49 30/12/2001, Mike Robinson wrote: Zeev Suraski writes: Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. You betcha, wrong ideas I was about to activate the Omega-13. ;) Regards Mike Robinson -- 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] pgsql session save handler bench (was [PHP-DEV] session_pgsql module commit notice)
PostgreSQL has one real behavior problem. Updates act as if you do a delete then an insert, i.e. for transactional isolation, an updated row is added new, and the old one is marked as deleted. Sessions are all about updates, and any really active server cluster will expose PostgreSQL's worst behavior. I agree. It will slows down thing a *LOT*. But it's faster than files save handler with proper administration, I suppose. I actually doubt it it will be. An insert into a database like PostgreSQL has a lot more overhead than just the basic file manipulation. Both I and you could be wrong :) File system like Ext2, uses liner search for dir entry and dir operation is atomic in OS. This is a lot of overheads. However, newer FS like ReiserFS/XFS/Ext3 uses Btree for dir entry that helps a lot. PostgreSQL is using MVCC. Therefore, it could be faster for many session data. It also can share session data with multiple web servers. Anyone care to take benchmarks? (You need to wait a little more, since session module needed to be changed to work with pgsql session save handler) I got a little time to take some simple benchmarks using ApacheBench 1.3d. OS: Linux 2.4.4/glibc 2.2.2 PC: Intel Celeron 433Mhz/384MB RAM/ATA33 EIDE HDD PostgreSQL: 7.1.3 installed on the same PC Filesystem: ReiserFS PHP: Debug enabled 4.2.0-dev/Apache SAPI There are 5000 session data stored already. Addtional 5000 session data is created by ab -n 5000 URL Files handler: Requests per second:95.44 [#/sec] (mean) Pgsql handler: Requests per second:68.98 [#/sec] (mean) If btree is used for index, PostreSQL slows down a lot. I used hash for index. Most of CPU time is used by PostgreSQL during benchmark. If PostgreSQL server is installed in other PC, pgsql result may be close to files handler. Ext2 FS users may get slower performance with files handler. (Or faster for 10K sessions?) -- Yasuo Ohgaki -- 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] Bug #14758: $HTTP_GET_VARS Improper NAME scrambling
From: [EMAIL PROTECTED]
Operating system: Linux 2.4 (Mandrake 6.1)
PHP version: 4.0.6
PHP Bug Type: *General Issues
Bug description: $HTTP_GET_VARS Improper NAME scrambling
? if (!sizeof($HTTP_GET_VARS) ) { ?
FORM ACTION=?=$PHP_SELF? METHOD=GET
INPUT TYPE=TEXT NAME=Test Input VALUE=doh!
INPUT TYPE=SUBMIT
/FORM
?} else { ?
This won't work (it should):?=$HTTP_GET_VARS['Test Input']?BR
This will:?=$HTTP_GET_VARS['Test_Input']?BR
? } ?
--
Edit bug report at: http://bugs.php.net/?id=14758edit=1
--
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] Bug #14758 Updated: $HTTP_GET_VARS Improper NAME scrambling
ID: 14758
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: *General Issues
Operating System: Linux 2.4 (Mandrake 6.1)
PHP Version: 4.0.6
New Comment:
Since spaces aren't allowed in variable names (obviously) they're converted to
underscores. Bo bug - bogus.
Previous Comments:
[2001-12-29 22:34:54] [EMAIL PROTECTED]
? if (!sizeof($HTTP_GET_VARS) ) { ?
FORM ACTION=?=$PHP_SELF? METHOD=GET
INPUT TYPE=TEXT NAME=Test Input VALUE=doh!
INPUT TYPE=SUBMIT
/FORM
?} else { ?
This won't work (it should):?=$HTTP_GET_VARS['Test Input']?BR
This will:?=$HTTP_GET_VARS['Test_Input']?BR
? } ?
Edit this bug report at http://bugs.php.net/?id=14758edit=1
--
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]
