[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Wez Furlong
On 10/29/02, Marcus B?rger [EMAIL PROTECTED] wrote:
   -Use // instead of /* ... */ comments

Why?

   #this test fails for me. Very weired...

You changed the test.
Why not ask me first about it failing?

--Wez.




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Marcus Börger
I started to work on that issue. My first attempt was to check where and
why the test failed. I used the comment modification because it seems
the test fails due to some internal failure.

The reason i did not ask you before was that i considered my changes
a kind of whitespace change so that any further change can easily be
seen.

The question i would like to ask now we already talk about this is:
When i comment out everythink starting at ob_start() i get some
output. If not (original) then i don't get any output. What is weired is
that when i use any print/echo statement after ob_end_xxx() nothing
is printed...

The length of the lyrics added by me was only to test whether or not that
part of the script works.

marcus

At 15:25 29.10.2002, Wez Furlong wrote:

On 10/29/02, Marcus B?rger [EMAIL PROTECTED] wrote:
   -Use // instead of /* ... */ comments

Why?

   #this test fails for me. Very weired...

You changed the test.
Why not ask me first about it failing?

--Wez.



--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Wez Furlong
Lets stick to C comments, as those are the preference listed in 
coding standards (and C++ style comments are really only intended
for single line out-commenting anyhow).

The test works fine here; it relies on output buffering working correctly;
when the test passes you see only the expected output.  If it fails, you
see a trace of the seek offsets and expected positioning etc. etc.

The failure of the test for you, and also the strange behaviour when
changing the ob_xxx calls points a finger at the output buffer layer.

Lets just make it a point to discuss something before changing someone
elses code: comments and coding styles are often a touchy subject with
a lot of developers (I'm normally fine with it, but it seemed pointless
in this case, and against our general coding standards.)

--Wez.


On 10/29/02, Marcus Börger [EMAIL PROTECTED] wrote:
 I started to work on that issue. My first attempt was to check where and
 why the test failed. I used the comment modification because it seems
 the test fails due to some internal failure.
 
 The reason i did not ask you before was that i considered my changes
 a kind of whitespace change so that any further change can easily be
 seen.
 
 The question i would like to ask now we already talk about this is:
 When i comment out everythink starting at ob_start() i get some
 output. If not (original) then i don't get any output. What is weired is
 that when i use any print/echo statement after ob_end_xxx() nothing
 is printed...
 
 The length of the lyrics added by me was only to test whether or not that
 part of the script works.
 
 marcus
 
 At 15:25 29.10.2002, Wez Furlong wrote:
 On 10/29/02, Marcus B?rger [EMAIL PROTECTED] wrote:
 -Use // instead of /* ... */ comments
 
 Why?
 
 #this test fails for me. Very weired...
 
 You changed the test.
 Why not ask me first about it failing?
 
 --Wez.




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Marcus Börger
This test fails with adding
--INI--
output_buffering=0
output_handler=
zlib.output_compression=
implicit_flush=0

and even when removing the three calls to ob_xxx89

At 15:59 29.10.2002, Wez Furlong wrote:

Lets stick to C comments, as those are the preference listed in
coding standards (and C++ style comments are really only intended
for single line out-commenting anyhow).

The test works fine here; it relies on output buffering working correctly;
when the test passes you see only the expected output.  If it fails, you
see a trace of the seek offsets and expected positioning etc. etc.

The failure of the test for you, and also the strange behaviour when
changing the ob_xxx calls points a finger at the output buffer layer.

Lets just make it a point to discuss something before changing someone
elses code: comments and coding styles are often a touchy subject with
a lot of developers (I'm normally fine with it, but it seemed pointless
in this case, and against our general coding standards.)

--Wez.


On 10/29/02, Marcus Börger [EMAIL PROTECTED] wrote:
 I started to work on that issue. My first attempt was to check where and
 why the test failed. I used the comment modification because it seems
 the test fails due to some internal failure.

 The reason i did not ask you before was that i considered my changes
 a kind of whitespace change so that any further change can easily be
 seen.

 The question i would like to ask now we already talk about this is:
 When i comment out everythink starting at ob_start() i get some
 output. If not (original) then i don't get any output. What is weired is
 that when i use any print/echo statement after ob_end_xxx() nothing
 is printed...

 The length of the lyrics added by me was only to test whether or not that
 part of the script works.

 marcus

 At 15:25 29.10.2002, Wez Furlong wrote:
 On 10/29/02, Marcus B?rger [EMAIL PROTECTED] wrote:
 -Use // instead of /* ... */ comments
 
 Why?
 
 #this test fails for me. Very weired...
 
 You changed the test.
 Why not ask me first about it failing?
 
 --Wez.




--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Wez Furlong
On 10/29/02, Marcus Börger [EMAIL PROTECTED] wrote:
 This test fails with adding
 --INI--
 output_buffering=0
 output_handler=
 zlib.output_compression=
 implicit_flush=0

Works fine here.
 
 and even when removing the three calls to ob_xxx89

Can you email me the output?
Also, could you strace it too? (just to be sure)

--Wez.


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Marcus Börger
At 16:36 29.10.2002, Wez Furlong wrote:

On 10/29/02, Marcus Börger [EMAIL PROTECTED] wrote:
 This test fails with adding
 --INI--
 output_buffering=0
 output_handler=
 zlib.output_compression=
 implicit_flush=0

Works fine here.

 and even when removing the three calls to ob_xxx89

Can you email me the output?


There is no output


Also, could you strace it too? (just to be sure)



[marcus@zaphod php4-HEAD]$ strace php ext/standard/tests/file/userstreams.php
execve(/usr/src/php4-HEAD/sapi/cli/php, [php, 
ext/standard/tests/file/userstreams.php], [/* 39 vars */]) = 0
uname({sys=Linux, node=zaphod, ...}) = 0
brk(0)  = 0x82886e4
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or directory)
open(/usr/local/lib/i686/mmx/libsablot.so.0, O_RDONLY) = -1 ENOENT (No 
such file or directory)
stat64(/usr/local/lib/i686/mmx, 0xbfffecdc) = -1 ENOENT (No such file or 
directory)
open(/usr/local/lib/i686/libsablot.so.0, O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64(/usr/local/lib/i686, 0xbfffecdc) = -1 ENOENT (No such file or 
directory)
open(/usr/local/lib/mmx/libsablot.so.0, O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64(/usr/local/lib/mmx, 0xbfffecdc) = -1 ENOENT (No such file or 
directory)
open(/usr/local/lib/libsablot.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20H\4\000..., 
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=2611187, ...}) = 0
old_mmap(NULL, 1062104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40016000
mprotect(0x400eb000, 189656, PROT_NONE) = 0
old_mmap(0x400eb000, 188416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 
3, 0xd4000) = 0x400eb000
old_mmap(0x40119000, 1240, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40119000
close(3)= 0
open(/usr/local/lib/libjs.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/X11R6/lib/i686/mmx/libjs.so, O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64(/usr/X11R6/lib/i686/mmx, 0xbfffeccc) = -1 ENOENT (No such file or 
directory)
open(/usr/X11R6/lib/i686/libjs.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64(/usr/X11R6/lib/i686, 0xbfffeccc) = -1 ENOENT (No such file or 
directory)
open(/usr/X11R6/lib/mmx/libjs.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64(/usr/X11R6/lib/mmx, 0xbfffeccc) = -1 ENOENT (No such file or 
directory)
open(/usr/X11R6/lib/libjs.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64(/usr/X11R6/lib, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=53720, ...}) = 0
old_mmap(NULL, 53720, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4011a000
close(3)= 0
open(/usr/lib/libjs.so, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300u\1..., 1024) 
= 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=445580, ...}) = 0
old_mmap(NULL, 449188, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40128000
mprotect(0x40192000, 15012, PROT_NONE)  = 0
old_mmap(0x40192000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x69000) = 0x40192000
close(3)= 0
open(/usr/local/lib/libexpat.so.0, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/X11R6/lib/libexpat.so.0, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/lib/libexpat.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@%\0\000..., 1024) 
= 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=178576, ...}) = 0
old_mmap(NULL, 181656, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40196000
mprotect(0x401b9000, 38296, PROT_NONE)  = 0
old_mmap(0x401b9000, 40960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x22000) = 0x401b9000
close(3)= 0
open(/usr/local/lib/libpq.so.2, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/X11R6/lib/libpq.so.2, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/lib/libpq.so.2, O_RDONLY)   = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3004\0..., 1024) 
= 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=71712, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x401c3000
old_mmap(NULL, 74816, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401c4000
mprotect(0x401d5000, 5184, PROT_NONE)   = 0
old_mmap(0x401d5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x1) = 0x401d5000
close(3)= 0
open(/usr/local/lib/libmhash.so.2, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/X11R6/lib/libmhash.so.2, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/lib/libmhash.so.2, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\32..., 1024) 
= 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=132160, ...}) = 0
old_mmap(NULL, 135240, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x401d7000

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Wez Furlong
OK, so how about a backtrace ?

--Wez.

On Tue, 29 Oct 2002, Marcus [iso-8859-1] Börger wrote:

 At 16:36 29.10.2002, Wez Furlong wrote:

 Also, could you strace it too? (just to be sure)

 old_mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
 0) = 0x407d5000
 read(3, ...naq gur ebnq orpbzrf zl oevqr..., 8192) = 8192
 lseek(3, 0, SEEK_SET)   = 0
 --- SIGSEGV (Segmentation fault) ---
 +++ killed by SIGSEGV +++




--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Marcus Börger
(gdb) file /usr/src/php4-HEAD/sapi/cli/php
Reading symbols from /usr/src/php4-HEAD/sapi/cli/php...done.
(gdb) set args ext/standard/tests/file/userstreams.phpt
(gdb) run
Starting program: /usr/src/php4-HEAD/sapi/cli/php 
ext/standard/tests/file/userstreams.phpt
[New Thread 1024 (LWP 13760)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 13760)]
0x081cb069 in zend_assign_add_obj_handler (execute_data=0xbfffa520,
op_array=0x407581bc, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/Zend/zend_execute.c:232
232 if ((*object_ptr)-type == IS_NULL
(gdb) bt
#0  0x081cb069 in zend_assign_add_obj_handler (execute_data=0xbfffa520,
op_array=0x407581bc, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/Zend/zend_execute.c:232
#1  0x081c34de in execute (op_array=0x407581bc, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/Zend/zend_execute.c:1194
#2  0x081a9f7c in call_user_function_ex (function_table=0x4073e74c,
object_pp=0x40798984, function_name=0xbfffa6a0, retval_ptr_ptr=0xbfffa694,
param_count=1, params=0xbfffa698, no_separation=0, symbol_table=0x0,
tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/Zend/zend_execute_API.c:646
#3  0x081944f7 in php_userstreamop_read (stream=0x40799760, buf=0x407cea4c ,
count=8192, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/main/user_streams.c:444
#4  0x0818cdb9 in php_stream_fill_read_buffer (stream=0x40799760, size=1023,
tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/main/streams.c:491
#5  0x0818d1e0 in _php_stream_get_line (stream=0x40799760, buf=0x407ce610 ,
maxlen=1024, returned_len=0xbfffa770, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/main/streams.c:758
#6  0x08120a1c in zif_fgets (ht=2, return_value=0x407cc368, this_ptr=0x0,
return_value_used=1, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/ext/standard/file.c:1341
#7  0x081d4bfa in zend_do_fcall_common_helper (execute_data=0xbfffd7b0,
op_array=0x40738864, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/Zend/zend_execute.c:2414
---Type return to continue, or q return to quit---
#8  0x081d5419 in zend_do_fcall_handler (execute_data=0xbfffd7b0,
op_array=0x40738864, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/Zend/zend_execute.c:2533
#9  0x081c34de in execute (op_array=0x40738864, tsrm_ls=0x82887b0)
at /usr/src/php4-HEAD/Zend/zend_execute.c:1194
#10 0x081b3177 in zend_execute_scripts (type=8, tsrm_ls=0x82887b0, retval=0x0,
file_count=3) at /usr/src/php4-HEAD/Zend/zend.c:862
#11 0x08183f99 in php_execute_script (primary_file=0xbab0,
tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/main/main.c:1541
#12 0x081dfa30 in main (argc=2, argv=0xbb44)
at /usr/src/php4-HEAD/sapi/cli/php_cli.c:695
#13 0x40561280 in __libc_start_main () from /lib/libc.so.6
(gdb)

At 19:02 29.10.2002, you wrote:
OK, so how about a backtrace ?

--Wez.

On Tue, 29 Oct 2002, Marcus [iso-8859-1] Börger wrote:

 At 16:36 29.10.2002, Wez Furlong wrote:

 Also, could you strace it too? (just to be sure)

 old_mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
 0) = 0x407d5000
 read(3, ...naq gur ebnq orpbzrf zl oevqr..., 8192) = 8192
 lseek(3, 0, SEEK_SET)   = 0
 --- SIGSEGV (Segmentation fault) ---
 +++ killed by SIGSEGV +++





--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

2002-10-29 Thread Wez Furlong
Is that ZE2?
There is no zend_assign_add_obj_handler function anywhere in my checkout
of HEAD + ZE1, and line 232 of zend_execute is a case statement in
my checkout.

I'm not concerned with ZE2 problems at this time (well, I am, but don't
have the time to support it).  Most likely, this is an issue with the
recent splitting of the opcode handlers; Andi would probably like to
see this backtrace.

--Wez.

On 29/10/02, Marcus Börger [EMAIL PROTECTED] wrote:
 (gdb) file /usr/src/php4-HEAD/sapi/cli/php
 Reading symbols from /usr/src/php4-HEAD/sapi/cli/php...done.
 (gdb) set args ext/standard/tests/file/userstreams.phpt
 (gdb) run
 Starting program: /usr/src/php4-HEAD/sapi/cli/php 
 ext/standard/tests/file/userstreams.phpt
 [New Thread 1024 (LWP 13760)]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 1024 (LWP 13760)]
 0x081cb069 in zend_assign_add_obj_handler (execute_data=0xbfffa520,
  op_array=0x407581bc, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/Zend/zend_execute.c:232
 232 if ((*object_ptr)-type == IS_NULL
 (gdb) bt
 #0  0x081cb069 in zend_assign_add_obj_handler (execute_data=0xbfffa520,
  op_array=0x407581bc, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/Zend/zend_execute.c:232
 #1  0x081c34de in execute (op_array=0x407581bc, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/Zend/zend_execute.c:1194
 #2  0x081a9f7c in call_user_function_ex (function_table=0x4073e74c,
  object_pp=0x40798984, function_name=0xbfffa6a0, retval_ptr_ptr=0xbfffa694,
  param_count=1, params=0xbfffa698, no_separation=0, symbol_table=0x0,
  tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/Zend/zend_execute_API.c:646
 #3  0x081944f7 in php_userstreamop_read (stream=0x40799760, buf=0x407cea4c ,
  count=8192, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/main/user_streams.c:444
 #4  0x0818cdb9 in php_stream_fill_read_buffer (stream=0x40799760, size=1023,
  tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/main/streams.c:491
 #5  0x0818d1e0 in _php_stream_get_line (stream=0x40799760, buf=0x407ce610 ,
  maxlen=1024, returned_len=0xbfffa770, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/main/streams.c:758
 #6  0x08120a1c in zif_fgets (ht=2, return_value=0x407cc368, this_ptr=0x0,
  return_value_used=1, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/ext/standard/file.c:1341
 #7  0x081d4bfa in zend_do_fcall_common_helper (execute_data=0xbfffd7b0,
  op_array=0x40738864, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/Zend/zend_execute.c:2414
 ---Type return to continue, or q return to quit---
 #8  0x081d5419 in zend_do_fcall_handler (execute_data=0xbfffd7b0,
  op_array=0x40738864, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/Zend/zend_execute.c:2533
 #9  0x081c34de in execute (op_array=0x40738864, tsrm_ls=0x82887b0)
  at /usr/src/php4-HEAD/Zend/zend_execute.c:1194
 #10 0x081b3177 in zend_execute_scripts (type=8, tsrm_ls=0x82887b0, retval=0x0,
  file_count=3) at /usr/src/php4-HEAD/Zend/zend.c:862
 #11 0x08183f99 in php_execute_script (primary_file=0xbab0,
  tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/main/main.c:1541
 #12 0x081dfa30 in main (argc=2, argv=0xbb44)
  at /usr/src/php4-HEAD/sapi/cli/php_cli.c:695
 #13 0x40561280 in __libc_start_main () from /lib/libc.so.6
 (gdb)
 
 At 19:02 29.10.2002, you wrote:
 OK, so how about a backtrace ?
 
 --Wez.
 
 On Tue, 29 Oct 2002, Marcus [iso-8859-1] Börger wrote:
 
   At 16:36 29.10.2002, Wez Furlong wrote:
 
   Also, could you strace it too? (just to be sure)
  
   old_mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
   0) = 0x407d5000
   read(3, ...naq gur ebnq orpbzrf zl oevqr..., 8192) = 8192
   lseek(3, 0, SEEK_SET)   = 0
   --- SIGSEGV (Segmentation fault) ---
   +++ killed by SIGSEGV +++
  
  




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php