Re: [PHP-DEV] Can't build HEAD on Linux
Sebastian Bergmann wrote: I updated to gcc 3.2 a while ago and it worked fine. This morning, for instance, I was able to build HEAD without problems. Just now I was able to build httpd-2.0 HEAD without problems. I updated binutils and did a fresh checkout of /php4. Now it works again. -- 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, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. - millions of decent programmers who are used to _usual_ behavior. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. If we are argue about difficulty of flushing, - there are many tiny small things that may not be trivial to newbies, flush may be one of them. They should learn these simple idioms anyway. - line buffering is easy enough to learn. Even newbies should find it flushes with newline. It should be enough for them, if they cannot find/learn flush(). - are we going to detect things that may not be intuitive to newbies? e.g. infinite loop/recusion, etc. I guess not. implicit_flush=On by default is bad for both newbies and experienced users. Newbies (even experienced users) write inefficient programs, since they don't know auto flushing. Experienced users have to unset auto flushing almost always. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Mike Ford wrote: BTW, real language (i.e. not shell) don't flush. Please let me know if there is real language that do automatic flushing by default. But PHP-CLI *is* a shell-scripting language, and therefore should behave like one. Other flavours of PHP aren't, and shouldn't. QED. You explained yourself as experienced programmer, but please research what is shell. Do you have this in your /etc/passwd file ;) root:x:0:0:root:/root:/bin/php Try that, it should be fun to use php as shell. Don't forget to copy your php binary to /bin! -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Mike,
It seems my last mail is a bit too negative. Sorry.
Mike Ford wrote:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
I'm referring to actual shell used for user interface, such as
bash, csh.
AFAIK, all shells flushes automatically, but no programing language
that is designed for programming do not flush.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
If people would like to a script that can be used as filter,
auto flushing is evil.
If people writing interactive CUI programs,
function prompt($prefix) {
echo $prefix;
flush();
}
is enough.
Line buffering is enough for all most all purposes.
Don't forget auto flushing make system call flush stream twice
with following script always.
echo abc\n;
And flushing is relatively heavy thing to do.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
I think only very little CLI programs, less than 1%, a few %
at most, need auto flushing.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Yasuo,
can you please stop this discussion now, it's not going to change. It
only wastes time which we could have spend on numerous other things for
PHP, such as fixing bugs and writing tests for the test system.
Derick
On Fri, 25 Oct 2002, Yasuo Ohgaki wrote:
Mike,
It seems my last mail is a bit too negative. Sorry.
Mike Ford wrote:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
I'm referring to actual shell used for user interface, such as
bash, csh.
AFAIK, all shells flushes automatically, but no programing language
that is designed for programming do not flush.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
If people would like to a script that can be used as filter,
auto flushing is evil.
If people writing interactive CUI programs,
function prompt($prefix) {
echo $prefix;
flush();
}
is enough.
Line buffering is enough for all most all purposes.
Don't forget auto flushing make system call flush stream twice
with following script always.
echo abc\n;
And flushing is relatively heavy thing to do.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
I think only very little CLI programs, less than 1%, a few %
at most, need auto flushing.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal for naming tests
Hello, to make easier maintenance and checking possible I would suggest to name our tests more appropriate: Class: Name: Example: Tests for bugs bugbugid.phptbug17123.phpt Tests for functions functionname.phptdba_open.phpt General tests for extensions extnameno.phpt dba3.phpt I do not see a real use to rename tests, but IMO this is the way to go for newly written tests. Of course renaming tests is ok too if you like to do that :) regards, Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for naming tests
+1 Moriyoshi Derick Rethans [EMAIL PROTECTED] wrote: Hello, to make easier maintenance and checking possible I would suggest to name our tests more appropriate: Class: Name: Example: Tests for bugs bugbugid.phptbug17123.phpt Tests for functions functionname.phptdba_open.phpt General tests for extensions extnameno.phpt dba3.phpt I do not see a real use to rename tests, but IMO this is the way to go for newly written tests. Of course renaming tests is ok too if you like to do that :) regards, Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ --- -- 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
[PHP-DEV] SessionID and XHTML
In my PHP-Version, Session-IDs are appended like this: script.php?foo=4PHPSESSID=344e... To be XHTML1-compliant it should be done this way: script.php?foo=4amp;PHPSESSID=344e... Is there any way I could PHP force to do this except adding the Session-IDs manually or change the PHP-Code? Sorry, if this has already been implemented in the CVS-Version. Jens -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SessionID and XHTML
On Fri, 25 Oct 2002, Jens Lehmann wrote: In my PHP-Version, Session-IDs are appended like this: script.php?foo=4PHPSESSID=344e... To be XHTML1-compliant it should be done this way: script.php?foo=4amp;PHPSESSID=344e... Is there any way I could PHP force to do this except adding the Session-IDs manually or change the PHP-Code? Sorry, if this has already been implemented in the CVS-Version. php.ini setting: ; The separator used in PHP generated URLs to separate arguments. ; Default is . ;arg_separator.output = amp; Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SessionID and XHTML
On Fri, 25 Oct 2002, Jens Lehmann wrote: In my PHP-Version, Session-IDs are appended like this: script.php?foo=4PHPSESSID=344e... To be XHTML1-compliant it should be done this way: script.php?foo=4amp;PHPSESSID=344e... Is there any way I could PHP force to do this except adding the Session-IDs manually or change the PHP-Code? Sorry, if this has already been implemented in the CVS-Version. php.ini setting: ; The separator used in PHP generated URLs to separate arguments. ; Default is . ;arg_separator.output = amp; Thank you! (If I knew there's a solution I would have posted to php.general of course.) Jens -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Proposal for naming tests
At 11:57 25-10-2002, Derick Rethans wrote:
to make easier maintenance and checking possible I would suggest to name
our tests more appropriate:
+1
Class: Name: Example:
Tests for bugs bugbugid.phptbug17123.phpt
Tests for functions functionname.phptdba_open.phpt
General tests for extensions extnameno.phpt dba3.phpt
+same for multiple tests on the same function.
I do not see a real use to rename tests, but IMO this is the way to go
for newly written tests. Of course renaming tests is ok too if you like
to do that :)
There's one drawback. Extensions with names after 'b' get evaluated after
the bug tests.
This is currently not a problem, but I've been playing with the thought to
introduce 'skip_ext' to speed things up:
--SKIP--
?php if(!extension_loaded('dba3')) { die(skip_ext this extension is not
available); } ?
But of course you can just tell me to stop playing with the tought :)
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for naming tests
On Fri, Oct 25, 2002 at 11:57:34AM +0200, Derick Rethans wrote: to make easier maintenance and checking possible I would suggest to name our tests more appropriate: Class: Name: Example: Tests for bugs bugbugid.phptbug17123.phpt Tests for functions functionname.phptdba_open.phpt General tests for extensions extnameno.phpt dba3.phpt +1 Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Proposal for naming tests
On Fri, 25 Oct 2002, Melvyn Sopacua wrote:
At 11:57 25-10-2002, Derick Rethans wrote:
[snip]
I do not see a real use to rename tests, but IMO this is the way to go
for newly written tests. Of course renaming tests is ok too if you like
to do that :)
There's one drawback. Extensions with names after 'b' get evaluated after
the bug tests.
This is currently not a problem, but I've been playing with the thought to
introduce 'skip_ext' to speed things up:
--SKIP--
?php if(!extension_loaded('dba3')) { die(skip_ext this extension is not
available); } ?
But of course you can just tell me to stop playing with the tought :)
Hereby I tell you to stop playing with that thought :P No, serious... I
don't think we really need this, and is speed really that important?
(The whole suite runs in under a minute here with about 75% of the
extensions).
Derick
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Proposal for naming tests
At 12:49 25-10-2002, Derick Rethans wrote:
[...]
There's one drawback. Extensions with names after 'b' get evaluated after
the bug tests.
This is currently not a problem, but I've been playing with the thought to
introduce 'skip_ext' to speed things up:
--SKIP--
?php if(!extension_loaded('dba3')) { die(skip_ext this extension is not
available); } ?
But of course you can just tell me to stop playing with the tought :)
Hereby I tell you to stop playing with that thought :P No, serious... I
don't think we really need this, and is speed really that important?
(The whole suite runs in under a minute here with about 75% of the
extensions).
Well - my testmachine at home, is a Cyrix 200MMX, with 128Mb, so it runs a
little longer than that :-)
And no - it's not that important - I'm just impatient sometimes :)
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pcntl_signal problem
Hi,
i've a small problem with the signal handler.
These short script demonstrate my problem.
#!/usr/local/bin/php
?php
set_time_limit(0);
function signals($signo) {
switch($signo) {
case SIGTERM:
echo Termination signal;
exit;
break;
case SIGINT:
echo Interrupt from keyboard;
exit
break;
}
}
$result=pcntl_signal(SIGTERM, 'signals');
if ($result == false) echo 'could not install sighandler for TERM';
$result=pcntl_signal(SIGINT,'signals');
if ($result == false) echo 'could not install sighandler for INT';
echo goto loop ...\n;
$c=0;
while (true){
$c++;
usleep(1);
}
?
The problem is, that the script doesnt exit when i'm
sending the TERM signal or pressing CTRL-C (INT signal).
I've test it with the lastest cvs version.
Any help?
Regards,
Steve
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP with FTP support on a Raq4 Server
Hi People, I am running PHP 4.1.2 on a Cobalt Raq4 server. I'm pretty new to Linux and can't understand why the server has come preinstalled with 2 diffrent versions of PHP. When I run phpinfo() from scripts on the site through my browser it says PHP is installed as an Apache module, but when I run it from the command line it still has the same version number but says its a CGI install. I'm trying to use the ftp_connect() function in a script that is run from the command line, ie. the CGI version and everytime I run it it says 'Call to undefined function ftp_connect()' yet when I run it through the browser on my site which is running the same version of PHP just the Apache module it works fine. Does anyone know what causes this strange behaviour or what I can do to get my ftp_connect() function working from the command line on a Raq4 server? Thanks for any help. Chris Morrow -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP with FTP support on a Raq4 Server
On Fri, Oct 25, 2002 at 01:39:15PM +0100, Chris Morrow wrote : Hi People, I am running PHP 4.1.2 on a Cobalt Raq4 server. I'm pretty new to Linux and can't understand why the server has come preinstalled with 2 diffrent versions of PHP. When I run phpinfo() from scripts on the site through my browser it says PHP is installed as an Apache module, but when I run it from the command line it still has the same version number but says its a CGI install. That's because the the Apache module (as the name says) is an module to Apache. You can't execute it directly from the shell, it only works within Apache. The CGI version on the other side works with stdin,stdout and stderr in both within an Webserver and so also on the shell. I'm trying to use the ftp_connect() function in a script that is run from the command line, ie. the CGI version and everytime I run it it says 'Call to undefined function ftp_connect()' yet when I run it through the browser on my site which is running the same version of PHP just the Apache module it works fine. Two possibilities: 1) The ftp extension is not compiled in, but a module The CGI version of PHP is using a different (or no) php.ini and thus hasn't loaded the ftp exetension. solution: use dl() or fix your php.ini 2) Your CGI is not compiled with ftp support and it's compiled in into the apache version, thus it's not available as a module. solution 1: compile only the ftp extension, load it as module (see 1 above) solution 2: recompile php HTH, btw, this is the wrong list. You should ask such question at [EMAIL PROTECTED] -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc $ grep docref_root php.ini docref_root = http://landonize.it/?how=urltheme=classicfilter=RichyHuser=imajesurl=http%3A%2F%2Fphp.net%2F/; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pcntl_signal problem
There were some changes to the pcntl extension. Have a look at
http://www.zend.com/lists/php-dev/200208/msg00937.html
Edin
- Original Message -
From: Steve Alberty [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 25, 2002 2:35 PM
Subject: [PHP-DEV] pcntl_signal problem
Hi,
i've a small problem with the signal handler.
These short script demonstrate my problem.
#!/usr/local/bin/php
?php
set_time_limit(0);
function signals($signo) {
switch($signo) {
case SIGTERM:
echo Termination signal;
exit;
break;
case SIGINT:
echo Interrupt from keyboard;
exit
break;
}
}
$result=pcntl_signal(SIGTERM, 'signals');
if ($result == false) echo 'could not install sighandler for TERM';
$result=pcntl_signal(SIGINT, 'signals');
if ($result == false) echo 'could not install sighandler for INT';
echo goto loop ...\n;
$c=0;
while (true){
$c++;
usleep(1);
}
?
The problem is, that the script doesnt exit when i'm
sending the TERM signal or pressing CTRL-C (INT signal).
I've test it with the lastest cvs version.
Any help?
Regards,
Steve
--
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] pcntl_signal problem
On Fri, 2002-10-25 at 08:50, Edin Kadribasic wrote: There were some changes to the pcntl extension. Have a look at http://www.zend.com/lists/php-dev/200208/msg00937.html Edin - Original Message - From: Steve Alberty [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 25, 2002 2:35 PM Subject: [PHP-DEV] pcntl_signal problem Hi, i've a small problem with the signal handler. These short script demonstrate my problem. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php Steve, Take a look at the ticks section of that email Edin sent you. Signal callbacks can now only occur if ticks is enabled for either a section of your code, or if they are globaly enabled. Steve + Edin + Everyone else, I will be updating the documentation to explain this before 4.3 is released, but I wonder If I should have configure spit out a reminder whenever someone enables pcntl Any thoughts on that? Thanks, -Jason -- Jason Greene [EMAIL PROTECTED] [EMAIL PROTECTED] Computer programmers never die, they just get lost in the processing. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pcntl_signal problem
On Fri, Oct 25, 2002 at 11:50:46AM -0500, Jason Greene wrote : I will be updating the documentation to explain this before 4.3 is released, but I wonder If I should have configure spit out a reminder whenever someone enables pcntl -1 No reminder, no E_WARNING. People should read the docs and, pcntl is still EXPERIMENTAL after all. But what I think after all would be a could idea to mention this little info in the NEWS entry (that ticks are needed) and refer them to the documentation from there. People will start from the NEWS file first. -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc $ grep docref_root php.ini docref_root = http://landonize.it/?how=urltheme=classicfilter=RichyHuser=imajesurl=http%3A%2F%2Fphp.net%2F/; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Where is the http connection shut down?
I'm trying to add my new function, register_offline_function, and have it
pretty much finished, but need a few pointers.
The php_request_function in main/main.c is where I'm working currently.
I've set up the function very similarly to the current
register_shutdown_function mechanism, and I've changed the
php_request_shutdown function to:
void php_request_shutdown(void *dummy)
{
TSRMLS_FETCH();
zend_try {
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1
) TSRMLS_CC);
} zend_end_try();
zend_try {
sapi_send_headers(TSRMLS_C);
} zend_end_try();
if (PG(modules_activated)) zend_try {
php_call_shutdown_functions();
} zend_end_try();
if (PG(modules_activated)) {
zend_deactivate_modules(TSRMLS_C);
}
/* Need to call something to close the http connection. */
if (PG(modules_activated)) zend_try {
fprintf(stderr, Calling Offline Functions.\n);
php_call_offline_functions();
} zend_end_try();
zend_try {
int i;
for (i=0; iNUM_TRACK_VARS; i++) {
if (PG(http_globals)[i]) {
zval_ptr_dtor(PG(http_globals)[i]);
}
}
} zend_end_try();
zend_deactivate(TSRMLS_C);
zend_try {
sapi_deactivate(TSRMLS_C);
} zend_end_try();
zend_try {
shutdown_memory_manager(CG(unclean_shutdown), 0 TSRMLS_CC);
} zend_end_try();
zend_try {
zend_unset_timeout(TSRMLS_C);
} zend_end_try();
}
I've tried moving the php_call_offline_functions() further down the
execution chain, but I can't put it after the zval_ptr_dtor loop, or move
the zend_deactivate() call up to be before it because these calls toast the
hashtable that stores the functions. What I'd really like to do is extract
the call that shuts down the http connection from the shutdown procedure and
move it into main.c if possible. Problem is that I can't figure out where
that happens. Is there a better way to do this?
Joseph
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] My email broke
Hi, My email was dead in the past 24 hours. All email I received was lost. If there's anything important you wanted me to read please email it to me again. Thanks, Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php
I haven't installed xslt yet so i do not know...but i am testing with 25% of the modules and get the feeling that we must check for all warnings and errors. A special situation is ext/session/tests/008-php4.2.3.phpt where a warning mechanism is checked..here the following would be enough --EXPECTF-- %s(%d) : Warning - Your %s But perhaps it would be a better solution to automatically add ?php echo $error_msg; ? at the end of each FILE section and set track_errors=1, display_errors=0, log_errors=0. At 21:41 25.10.2002, Melvyn Sopacua wrote: At 21:27 25-10-2002, Marcus Börger wrote: It should not break any test...please send a list of those failed. ext/xslt/xslt-001.phpt (used to be 009.phpt). log_errors=1 on cli, is /dev/stderr. Ilia: Could you take a look at the message I sent regarding your fix of that test? There are other problems with memory leaks (display_memleak and --disable-debug), so I'm enclined to drop this test - the format of the error message is not important and not what we we're testing. I've wrapped the procedure that caused the memleak in the first place into a macro, and used that. Any future places this should occur, we'll use the macro. marcus At 19:24 25.10.2002, Ilia Alshanetsky wrote: iliaa Fri Oct 25 13:24:10 2002 EDT Modified files: /php4 run-tests.php Log: The log_errors=1 breaks a number of tests and is useless for our purposes, removing. Index: php4/run-tests.php diff -u php4/run-tests.php:1.89 php4/run-tests.php:1.90 --- php4/run-tests.php:1.89 Thu Oct 24 14:14:39 2002 +++ php4/run-tests.php Fri Oct 25 13:24:09 2002 -484,7 +484,7 -d 'disable_functions=', -d 'error_reporting=2047', -d 'display_errors=0', - -d 'log_errors=1', + -d 'log_errors=0', -d 'html_errors=0', -d 'docref_root=/phpmanual/', -d 'docref_ext=.html', -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- 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 / run-tests.php
On October 25, 2002 04:01 pm, Marcus Börger wrote: I haven't installed xslt yet so i do not know...but i am testing with 25% of the modules and get the feeling that we must check for all warnings and errors. A special situation is ext/session/tests/008-php4.2.3.phpt where a warning mechanism is checked..here the following would be enough --EXPECTF-- %s(%d) : Warning - Your %s But perhaps it would be a better solution to automatically add ?php echo $error_msg; ? at the end of each FILE section and set track_errors=1, display_errors=0, log_errors=0. That test was already slightly reworked (error reporting portion of the script) to do almost exactly that. The echoing of the error variable cannot be done at the end of the script, because if there are any other errors and/or warnings they would overwrite the value stored inside the variable. So, it needs to be printed as soon as the error occures. Ilia At 21:41 25.10.2002, Melvyn Sopacua wrote: At 21:27 25-10-2002, Marcus Börger wrote: It should not break any test...please send a list of those failed. ext/xslt/xslt-001.phpt (used to be 009.phpt). log_errors=1 on cli, is /dev/stderr. Ilia: Could you take a look at the message I sent regarding your fix of that test? There are other problems with memory leaks (display_memleak and --disable-debug), so I'm enclined to drop this test - the format of the error message is not important and not what we we're testing. I've wrapped the procedure that caused the memleak in the first place into a macro, and used that. Any future places this should occur, we'll use the macro. marcus At 19:24 25.10.2002, Ilia Alshanetsky wrote: iliaa Fri Oct 25 13:24:10 2002 EDT Modified files: /php4 run-tests.php Log: The log_errors=1 breaks a number of tests and is useless for our purposes, removing. Index: php4/run-tests.php diff -u php4/run-tests.php:1.89 php4/run-tests.php:1.90 --- php4/run-tests.php:1.89 Thu Oct 24 14:14:39 2002 +++ php4/run-tests.php Fri Oct 25 13:24:09 2002 -484,7 +484,7 -d 'disable_functions=', -d 'error_reporting=2047', -d 'display_errors=0', - -d 'log_errors=1', + -d 'log_errors=0', -d 'html_errors=0', -d 'docref_root=/phpmanual/', -d 'docref_ext=.html', -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- 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 / run-tests.php
But we are speaking about one single test. I mean multiple calls to $php_errormsg are allowed of cause. I was just looking for a solution to check whether a test produces any not wanted messages. marcus At 22:06 25.10.2002, Ilia A. wrote: On October 25, 2002 04:01 pm, Marcus Börger wrote: I haven't installed xslt yet so i do not know...but i am testing with 25% of the modules and get the feeling that we must check for all warnings and errors. A special situation is ext/session/tests/008-php4.2.3.phpt where a warning mechanism is checked..here the following would be enough --EXPECTF-- %s(%d) : Warning - Your %s But perhaps it would be a better solution to automatically add ?php echo $error_msg; ? at the end of each FILE section and set track_errors=1, display_errors=0, log_errors=0. That test was already slightly reworked (error reporting portion of the script) to do almost exactly that. The echoing of the error variable cannot be done at the end of the script, because if there are any other errors and/or warnings they would overwrite the value stored inside the variable. So, it needs to be printed as soon as the error occures. Ilia At 21:41 25.10.2002, Melvyn Sopacua wrote: At 21:27 25-10-2002, Marcus Börger wrote: It should not break any test...please send a list of those failed. ext/xslt/xslt-001.phpt (used to be 009.phpt). log_errors=1 on cli, is /dev/stderr. Ilia: Could you take a look at the message I sent regarding your fix of that test? There are other problems with memory leaks (display_memleak and --disable-debug), so I'm enclined to drop this test - the format of the error message is not important and not what we we're testing. I've wrapped the procedure that caused the memleak in the first place into a macro, and used that. Any future places this should occur, we'll use the macro. marcus At 19:24 25.10.2002, Ilia Alshanetsky wrote: iliaa Fri Oct 25 13:24:10 2002 EDT Modified files: /php4 run-tests.php Log: The log_errors=1 breaks a number of tests and is useless for our purposes, removing. Index: php4/run-tests.php diff -u php4/run-tests.php:1.89 php4/run-tests.php:1.90 --- php4/run-tests.php:1.89 Thu Oct 24 14:14:39 2002 +++ php4/run-tests.php Fri Oct 25 13:24:09 2002 -484,7 +484,7 -d 'disable_functions=', -d 'error_reporting=2047', -d 'display_errors=0', - -d 'log_errors=1', + -d 'log_errors=0', -d 'html_errors=0', -d 'docref_root=/phpmanual/', -d 'docref_ext=.html', -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- 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/xslt/tests xslt_setopt.phpt
At 22:36 25-10-2002, Ilia A. wrote: I've just tried the latest version of the xslt tests and ext/xslt/tests/xslt_setopt.phpt test fails. The failure is the result of expected output needing some non-ascii character after PHP QA. Where is this character comming from, the xml xslt style sheets do not seem to have any non-ascii data in them. It does work for me. It's an entity test, and it's in public.xml - reg;, which is ISO-8859-1. I can take an ASCII char of course. I think this only works when libiconv support is built-in to Sablotron, as it uses UTF-8 internally and relies on iconv for the conversions. This is a little hard to test for though. There are 2 possibilities: 1) we can use config.m4 to register a preprocessor symbol, then provide 'iconv' in some function like xslt_features() 2) we can ask the Sablotron guys to provide the information, so that it's available at runtime, via an API function. This is the most reliable option. In any case, did you provide --with-iconv-dir, so I'm 100% sure this is the problem? Ilia On October 25, 2002 03:17 pm, Melvyn Sopacua wrote: msopacua Fri Oct 25 15:17:15 2002 EDT Added files: /php4/ext/xslt/tests xslt-001.phpt xslt_process-001.phpt xslt_process-002.phpt xslt_set_object.phpt xslt_set_scheme_handlers-001.phpt xslt_setopt.phpt bug17791.phpt bug17931.phpt xslt.phpt Modified files: /php4/ext/xslt/tests skipif.inc Log: Tests renamed Remove dl() from skipif, for potential problems accross platforms and versions. Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Derick Rethans wrote:
Yasuo,
can you please stop this discussion now, it's not going to change. It
only wastes time which we could have spend on numerous other things for
PHP, such as fixing bugs and writing tests for the test system.
I don't want to waste my time too. I just trying to make PHP
a little better.
Anyway, can you please stop patching without full knowledge or
understanding issues? If you aren't certain, ask.
Recent examples are:
Makefile.global
- You insisted it should be INI independent without fixing
dependency issue
main.c
- You wrongly applied patch that enable without understanding
the patch is bogus with the code.
(I know you changed code more reasonable later, but it's still
not a good idea)
It's a waste of time, since it just makes discussion harder.
BTW, I think current output buffer code is not good enough.
It's much better to write it with streams. Think about
the implication of implicit flushing by default.
--
Yasuo Ohgaki
On Fri, 25 Oct 2002, Yasuo Ohgaki wrote:
Mike,
It seems my last mail is a bit too negative. Sorry.
Mike Ford wrote:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
I'm referring to actual shell used for user interface, such as
bash, csh.
AFAIK, all shells flushes automatically, but no programing language
that is designed for programming do not flush.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
If people would like to a script that can be used as filter,
auto flushing is evil.
If people writing interactive CUI programs,
function prompt($prefix) {
echo $prefix;
flush();
}
is enough.
Line buffering is enough for all most all purposes.
Don't forget auto flushing make system call flush stream twice
with following script always.
echo abc\n;
And flushing is relatively heavy thing to do.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
I think only very little CLI programs, less than 1%, a few %
at most, need auto flushing.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
I need to add a little. Zeev Suraski wrote: If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. Are you going to set output_buffering=Off by default, too? Since the obscurity still exists with output buffers. It's even worse with broken output buffer function. BTW, I don't object to have output_buffering=Off by default for CLI, since it's default of php.ini-dist and it does not make much sense for CLI. However, I objects implicit_flush=On by default for reasons I mentioned. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
At 01:22 26-10-2002, Yasuo Ohgaki wrote: Makefile.global - You insisted it should be INI independent without fixing dependency issue Some settings cannot be hardcoded. Granted. Some we may want to hardcode for run-tests.php. Granted. php.ini-dist is not the one to do it with. It's purpose is to provide the default settings, for the DISTribution. You'll get discussions on what is better for run-tests.php, and it shouldn't matter for distribution defaults. Not a good idea. If there should be something to fix, via an ini file, than let's use php.ini-test. But let's agree on this FIRST, before changing stuff in files, that are maintained by people knowing core best, and/or which affects behavior accross the distribution. Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Building PHP 4.2.3 against GD 2.0.4
Hello, I've just joined the list to send this patch hoping this helps with the development of PHP... I wanted to build PHP 4.2.3 against gd 2.0.4 (latest version) and it would compile. I found the problem is one member of the gdIOCtx struct in gd_io.h has been renamed from "free" to "gd_free". Dunno if this change is present in gd 2.0.2 and 2.0.3 but it is in 2.0.4 and it wasn't in 2.0.1 So the solution is straightforward, just replace -free with -gd_free and it'll compile... I was wondering if someone else got this issue and also wondering how to properly fix it.. How should the source of the gd extension be hacked to allow compilation against GD 2.0.1 and GD 2.0.4??? I'm attaching a patch, the changes are in gd_ctx.c and gd.c under ../ext/gd in the PHP 4.2.3 tree. Thanks Antonio Ognio Lima,Peru -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RF
Melvyn Sopacua wrote: *SNIP* If there should be something to fix, via an ini file, than let's use php.ini-test. No objection from me, of course. It's even better since we don't care about changes in php.ini-dist. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: astone
I'd like to work on the documentation, cleaning up some of the comments and updating a few of the pages. So I guess that means phpdoc access :-) I might also get involved with the translations. Who sent me? Well... I just got back from PHPCon where I met Rasmus, yay! Jim Winstead suggested that I should sign up for CVS account. Jim noted that some pages had lots of comments, and I noted that some of the comments confused me and I wished I could fix them and update the docs! So here I am :-) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
