Re: [PHP-DEV] Re: #20035 [Asn->Opn]: __LINE__ miscounts with #!/path/php scripts

hi, (Zeev and Andi, and other core devlopers are surely familiar with this, but maybe I can help, too) the cause of this problem is something like this: (1) in sapi/cgi/cgi_main.c(1118) or sapi/cli/php_cli.c(643), if the very begginig of the script is '#', PHP strips that line. at that time,

[PHP-DEV] Test suite and user space (Was: Re: [PHP-DEV] I hope this is the last email about this :))

At 00:27 24-10-2002, Yasuo Ohgaki wrote: PS: If you would like to write INI independent scripts, I suggest you to use php.ini-recommended at least. You don't/ didn't know phps crashing and make test does not work well with php.ini-recommended, nonetheless, you're insisting there is no problems.

Re: [PHP-DEV] PHP and OCI8

On Wed, Oct 23, 2002 at 06:15:19PM +0200, Roderick Groesbeek wrote: > Howdy People, > > Info: > === > I am witnessing problems with PHP, Apache and OCI8. > We have profiles on our Oracle databases, so sessions get sniped if they > hang on to long. what do y

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:

Alan Knowles wrote: Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manua

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

Jon Parise wrote: I still do not understand what magical values in php.ini-dist need to be applied to run-tests.php and why those values, if they are so important, can't be explicitly enabled via ini_set() calls. Glad to explain :) If you install php.ini-recommended as you default php.ini for C

[PHP-DEV] Re: #20035 [Asn->Opn]: __LINE__ miscounts with #!/path/php scripts

Er...You propably know then where this stripping happens in PHP or Zend ?? (I couldn't find it..) --Jani On 23 Oct 2002 [EMAIL PROTECTED] wrote: > ID: 20035 > Updated by: [EMAIL PROTECTED] > Reported By: [EMAIL PROTECTED] >-Status: Assign

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

On Thu, Oct 24, 2002 at 07:27:31AM +0900, Yasuo Ohgaki wrote: > >So, once again, all I really want to know is what is so special about > >php.ini-dist? And what _specific_ settings do you (Yasuo) feel must > >be applied to run-tests.php in order to run properly? And why can't > >they just be spe

Re: [PHP-DEV] Re: Unsigned Problems Revisited

At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote: On Tue, 22 Oct 2002, Andi Gutmans wrote: > Jason knows that my stand on this one is that if we have >>> we really > should also have <<< which will clash with here-docs. Suggestions for > other operators such as his are a possibility. Wron

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:CLI behave like SH or PERL/RUBY/PYTHON?)

Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:CLI behave like SH or PERL/RUBY/PYTHON?)

Edin Kadribasic wrote: I thought that we have agreed that you should revert the patch. You can now change the default behavior by both ini_set() and .the -d switch if you don't like the default. Yes. It's ok as a temporally solution, but not as a long term. I explicitly wrote I would like to s

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC: CLI behave like SH or PERL/RUBY/PYTHON?)

I thought that we have agreed that you should revert the patch. You can now change the default behavior by both ini_set() and .the -d switch if you don't like the default. Edin On Thursday 24 October 2002 00:27, Yasuo Ohgaki wrote: > Derick Rethans wrote: > > On Wed, 23 Oct 2002, Yasuo Ohgaki w

[PHP-DEV] ZE2 questions

Why doesn't the function zend_list_insert expect a TSRM parameter and instead calls TSRMLS_FETCH()? marcus -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:CLI behave like SH or PERL/RUBY/PYTHON?)

Derick Rethans wrote: On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: Yes, since it should not set in php_cli.c. It's a lot confusing, bad thing to do with current code, inefficient, bad default, etc. It's a very good default Derick, It's a very _bad_ default. Fortunately, it's not released yet.

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

Jon Parise wrote: On Wed, Oct 23, 2002 at 05:38:09PM +0900, Yasuo Ohgaki wrote: Hi Ilia and Jon, Do you still think specifying ini used _for_ run-tests.php is bad thing? I hope I've explained enough. I think you don't care, do you? I don't want to involve myself in some sort of religious

Re: [PHP-DEV] from one hash to another, in an extension

On Wed, 23 Oct 2002, Tim Daly, Jr. wrote: > > You don't need to SEPARATE_ZVAL() in this case. > > I don't need to, or I need not to? Don't use SEPARATE_ZVAL() when copying zval from one hash to another. -Andrei http://www.gravitonic.com/ We all have photogr

Re: [PHP-DEV] from one hash to another, in an extension

On Wed, 23 Oct 2002, Tim Daly, Jr. wrote: > > I'm trying to figure out the right way to take an entry from one hash > table, and put it in another, in C. This is what I first tried: > > // naive attempt at > // $hash2["key"] = $hash1["key"]; > > zval **val; > > zend_hash_find(hash1, "key", str

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

At 17:40 23-10-2002, Derick Rethans wrote: On Wed, 23 Oct 2002, Melvyn Sopacua wrote: > At 14:29 23-10-2002, Derick Rethans wrote: > > >If people refuse to read documentatino for tool they don't deserve to > >use it. Come'n.. if you are professional enough to even run a testsuite > >then you're

Re: [PHP-DEV] from one hash to another, in an extension

Andrei Zmievski <[EMAIL PROTECTED]> writes: > On Wed, 23 Oct 2002, Tim Daly, Jr. wrote: ... > > zend_hash_find(hash1, "key", strlen("key")+1, (void **)&val); > > SEPARATE_ZVAL(val); > > zval_add_ref(val); > > zend_hash_update(hash2, "key", strlen("key")+1, (void *)val, NULL); ... > You don't

Re: [PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute.c phpdoc/scripts revcheck.php

Nothign to worry, you triggered a race condition of the script which generates this messages. We've seen this not the first time. Actually, someone else commited something the very same moment it seems: 2002-10-23 22:26 tom * revcheck.php: added file-sizes to fi

[PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute.cphpdoc/scripts revcheck.php

Any idea how that revcheck.php diff got into my Engine 2 patch? I commited from within the Zend/ directory. Should something be reverted there? Andi Delivered-To: [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: list-

Re: [PHP-DEV] Re: [PATCH] Make mb_convert_case() conform to UnicodeSpec

Sure, I hope they'll also think about having string conversion functions. Moriyoshi Wez Furlong <[EMAIL PROTECTED]> wrote: > If you know what you're doing, go ahead. > But, out of courtesy to the ucdata people who produced the basis of the > code, please Cc: them any patches that they might find

Re: [PHP-DEV] Re: [PATCH] Make mb_convert_case() conform to UnicodeSpec

If you know what you're doing, go ahead. But, out of courtesy to the ucdata people who produced the basis of the code, please Cc: them any patches that they might find useful. (ucdata is used by the openldap project). --Wez. On Thu, 24 Oct 2002, Moriyoshi Koizumi wrote: > Hi, > > AFAIK, UCDATA

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

> That's what the --INI-- section in the test files are for. You can hard > code ini settings for your test there. Okay, I'd just like to see how you think about it. Then, no problem :) Moriyoshi -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/

[PHP-DEV] .cvsignore and .php

is affecting: U tests/odbc-display.php U tests/odbc-t1.php U tests/odbc-t2.php U tests/odbc-t3.php U tests/odbc-t4.php U tests/odbc-t5.php U tests/run.php U tests/testpfpro.php U tests/testscanf.php if you still have these files locally, please incorporate them into .phpt files or rename. With ki

Re: [PHP-DEV] Re: Unsigned Problems Revisited

On Tue, 22 Oct 2002, Andi Gutmans wrote: > Jason knows that my stand on this one is that if we have >>> we really > should also have <<< which will clash with here-docs. Suggestions for > other operators such as his are a possibility. Wrong on two counts. The reality of twos-complement, bit

[PHP-DEV] from one hash to another, in an extension

I'm trying to figure out the right way to take an entry from one hash table, and put it in another, in C. This is what I first tried: // naive attempt at // $hash2["key"] = $hash1["key"]; zval **val; zend_hash_find(hash1, "key", strlen("key")+1, (void **)&val); SEPARATE_ZVAL(val); zval_add_ref

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

On Thu, 24 Oct 2002, Moriyoshi Koizumi wrote: > > This is not for me, it's the general idea that the test suite works > > whatever stupid ini settings a user made. If tests fail because of this, > > or the test suite doesn't work we need to fix the tests and the suite. > > That's the intention

[PHP-DEV] Bug #18930

Are there plans to fix this? I have a testcase here, but if this is a won't fix, I'd rather dump it. With kind regards, Melvyn Sopacua -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

> This is not for me, it's the general idea that the test suite works > whatever stupid ini settings a user made. If tests fail because of this, > or the test suite doesn't work we need to fix the tests and the suite. > That's the intention behind it all. This is not always the case... Some fun

Re: [PHP-DEV] Re: [PATCH] Make mb_convert_case() conform to Unicode Spec

Hi, AFAIK, UCDATA itself only offers character conversion facilities, not string conversion ones. Is it our job to discuss how to implement those string conversion functions? If you think so, I'll commit it because I might be one of those who know the right way to handle it. Moriyoshi Wez Fu

[PHP-DEV] Re: [PATCH] Make mb_convert_case() conform to Unicode Spec

Hi Moriyoshi, The code was taken from the ucdata package; I don't really know anything about the internals at this stage. It is probably best to talk to the ucdata guys - I don't have the URL to hand, but I'm sure you can find them using google. --Wez. On Thu, 24 Oct 2002, Moriyoshi Koizumi wrot

[PHP-DEV] [PATCH] Make mb_convert_case() conform to Unicode Spec

Hello Wez, IMO the current behaviour of mb_convert_case() with MB_CASE_TITLE looks a bit strange as per Unicode specification. --snip-- (cited from http://www.unicode.org/unicode/reports/tr21/) S3. toTitlecase(X) For each character C, find the preceding character B. ignore any intervening case

Re: [PHP-DEV] PHP and OCI8

"Roderick Groesbeek" <[EMAIL PROTECTED]> wrote... : > Howdy People, > > Info: > === > I am witnessing problems with PHP, Apache and OCI8. > We have profiles on our Oracle databases, so sessions get sniped if they > hang on to long. > > Problem: > == > T

Re: [PHP-DEV] Script Abortion

Wei Weng <[EMAIL PROTECTED]> wrote... : > d'oh I meant to ask "how". :) > > Here is my understanding of the reading the code: > > If PHP doesn't get the correct string length for the return value of > ap_rwrite call, then it knows the socket is broken, then it goes to > zend_bailout() to abort

[PHP-DEV] PHP and OCI8

Howdy People, Info: === I am witnessing problems with PHP, Apache and OCI8. We have profiles on our Oracle databases, so sessions get sniped if they hang on to long. Problem: == The PHP ocilogoff() call is not operating, as seen from the source. Is there s

Re: [PHP-DEV] Script Abortion

d'oh I meant to ask "how". :) Here is my understanding of the reading the code: If PHP doesn't get the correct string length for the return value of ap_rwrite call, then it knows the socket is broken, then it goes to zend_bailout() to abort the script. So that means if it is a script that gets

Re: [PHP-DEV] Script Abortion

Maxim Maletsky wrote: i think it already does. i think that was not the question, but *how*? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Script Abortion

i think it already does. -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // PHP for Beginners www.maxim.cx // my Home // my Wish List: ( Get me something! ) http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3 Wei Weng <[EMAIL PROTECTED]> wrote... : > I have a que

Re: [PHP-DEV] Unsigned Problems Revisited

Before I respond, I just though I would give a summary of how other languages solve this problem. - Perl: Always performs logical unsigned shift, unless "use integer" is in effect Java: >>>, >>>= (they do not have <<<.

[PHP-DEV] auto_prepend_file Revisited

I'm sorry if this will be a rehash of previous discussions, but I haven't been able to locate anything in the archives. I find auto_prepend_file invaluable, especially when used in http.conf within or directives. One limitation I've run into, however, is the ability to "stack" auto_prepend_fil

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

On Wed, 23 Oct 2002, Melvyn Sopacua wrote: > At 14:29 23-10-2002, Derick Rethans wrote: > > >If people refuse to read documentatino for tool they don't deserve to > >use it. Come'n.. if you are professional enough to even run a testsuite > >then you're certainly professional enough to read a READ

[PHP-DEV] Script Abortion

I have a question about PHP internal. How does PHP implement the browser related script abortion, such as when user hits the stop button in the browser, PHP can abort the script being executed in the background. Thanks Wei -- PHP Development Mailing List To unsubscribe,

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

I'm not a big fan of doing things the smart way. How hard is it to just set ob_implicit_flush() on and off? If you want it off, just set it off (or on, as the default ends up set) at the head of your script. George On Wednesday, October 23, 2002, at 04:11 AM, Kristian Koehntopp wrote: On Wed

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

At 14:29 23-10-2002, Derick Rethans wrote: If people refuse to read documentatino for tool they don't deserve to use it. Come'n.. if you are professional enough to even run a testsuite then you're certainly professional enough to read a README. Unrelated to the ini issue, but could a: if(isset(

Re: [PHP-DEV] Perl-Like Pre-Destined Array Designation

On Wed, Oct 23, 2002 at 04:13:03PM +0200, Maxim Maletsky wrote : > BTW, are there any plans working on PHP parser for release 5? This is already done, see the [EMAIL PROTECTED] . > --- > Maxim Maletsky > [EMAIL PROTECTED] Please use a proper signature separator. A proper one is '--

Re: [PHP-DEV] Perl-Like Pre-Destined Array Designation

BTW, are there any plans working on PHP parser for release 5? --- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // PHP for Beginners www.maxim.cx // my Home // my Wish List: ( Get me something! ) http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3 Zeev Suraski <[EM

RE: [PHP-DEV] The reason the way it is: About flushing... Please read and comment.

i think it's really quite simple.. be able to allow the developer the freedom to make their own mind up. As Harmut pointed out, some cli stuff needs implicit flushing. Other stuff doesn't -- i have many php scriptlets which do tasks for me that sh can't quite handle (or i don't know how to do it i

[PHP-DEV] The reason the way it is: About flushing... Please read and comment.

This is obvious to me but it seems I have to explain... (B (BThere are reasons why things are made in a certain way. (B (Bshells, by its nature, it's interactive for the most (Bpurposes, thus flushing every output make sense even (Bif it cost CPU time. (B (Bprogramming languages, by its nat

Re: [PHP-DEV] compile error with ZE2

On Wed, Oct 23, 2002 at 03:06:21PM +0200, Derick Rethans wrote : > On Wed, 23 Oct 2002, Jan Schneider wrote: > > > Zitat von Derick Rethans <[EMAIL PROTECTED]>: > > > > > hmm, I thought I fixed this by putting preprocessor defines around the > > > Overload extension... > > > > But it doesn't wo

Re: [PHP-DEV] Perl-Like Pre-Destined Array Designation

We're not planning to add it at this time. Zeev At 14:42 23/10/2002, Adam Voigt wrote: Ok, the other day a friend of mine showed me where you could address a position in an array in perl, before you even had the array returned. Essentially it would be this in php: echo explode(",",$somearray)[0

Re: [PHP-DEV] Perl-Like Pre-Destined Array Designation

At 15:10 23/10/2002 +0200, Maxim Maletsky wrote: Would be very nice to have since PHP v5. Guys? > > echo explode(",",$somearray)[0]; > I would love to see it happen. -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Perl-Like Pre-Destined Array Designation

Would be very nice to have since PHP v5. Guys? --- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // PHP for Beginners www.maxim.cx // my Home // my Wish List: ( Get me something! ) http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3 Adam Voigt <[EMAIL PROTECTED]> wr

Re: [PHP-DEV] compile error with ZE2

On Wed, 23 Oct 2002, Jan Schneider wrote: > Zitat von Derick Rethans <[EMAIL PROTECTED]>: > > > hmm, I thought I fixed this by putting preprocessor defines around the > > Overload extension... > > But it doesn't work. How is determined which engine version is being to used? with #ifndef ZEND_EN

Re: [PHP-DEV] compile error with ZE2

Zitat von Derick Rethans <[EMAIL PROTECTED]>: > On Wed, 23 Oct 2002, Markus Fischer wrote: > > > I think --disable-overload "fixes" this. That did it. > hmm, I thought I fixed this by putting preprocessor defines around the > Overload extension... But it doesn't work. How is determined wh

Re: [PHP-DEV] compile error with ZE2

At 14:40 23.10.2002, Derick Rethans wrote: On Wed, 23 Oct 2002, Markus Fischer wrote: > I think --disable-overload "fixes" this. hmm, I thought I fixed this by putting preprocessor defines around the Overload extension... Derick I also had to disable overload marcus -- PHP Development

[PHP-DEV] Perl-Like Pre-Destined Array Designation

Ok, the other day a friend of mine showed me where you could address a position in an array in perl, before you even had the array returned. Essentially it would be this in php: echo explode(",",$somearray)[0]; Which would give you the first position of what was returned from the explode function

Re: [PHP-DEV] compile error with ZE2

On Wed, 23 Oct 2002, Markus Fischer wrote: > I think --disable-overload "fixes" this. hmm, I thought I fixed this by putting preprocessor defines around the Overload extension... Derick -- --- Derick Rethans

Re: [PHP-DEV] compile error with ZE2

I think --disable-overload "fixes" this. On Wed, Oct 23, 2002 at 12:39:16PM +0200, Jan Schneider wrote : > Current php from cvs (head) and ZE2: > > /bin/sh libtool --silent --mode=compile gcc -Imain/ > -I/home/jan/software/php4/main/ -DPHP_ATOM_INC > -I/home/jan/software/php4/include -I/hom

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

On Wed, 23 Oct 2002, Marcus Börger wrote: > Derick this is nonsense! Yeah, start yelling. That will really help us all. > We developers can use php -c bla run-tests.php xyz > > But make is for automated things and for those not reading > README.TESTING where everything should be explained.

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global

Derick this is nonsense! We developers can use php -c bla run-tests.php xyz But make is for automated things and for those not reading README.TESTING where everything should be explained. The typical user who is just glad to be able to build his private distribution of php will just call 'ma

[PHP-DEV] compile error with ZE2

Current php from cvs (head) and ZE2: /bin/sh libtool --silent --mode=compile gcc -Imain/ -I/home/jan/software/php4/main/ -DPHP_ATOM_INC -I/home/jan/software/php4/include -I/home/jan/software/php4/main -I/home/jan/software/php4 -I/home/jan/software/php4/Zend -I/usr/include/libxml2 -I/usr/include/f

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Yasuo Ohgaki wrote: There is cons also. Users may be looking the file with tail... this user will most likely *expect* line-based output -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List <

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: > Edin Kadribasic wrote: > > Since your commit has a potential to break some programs that PEAR depends on, > > I still think that you should revert your patch. And I think that it should > > stay that way for 4.3.0. > > I'll take a look just few days, t

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

At 11:21 23/10/2002, Yasuo Ohgaki wrote: 2. in the script with ini_set() I've pointed out _MANY_ times that PG(implicit_flush) is INI_SYSTEM|INI_PERDIR That's a valid point. Note that you can still change it using ob_implicit_flush(). However, it should be changed to INI_ALL so that it c

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Edin Kadribasic wrote: Since your commit has a potential to break some programs that PEAR depends on, I still think that you should revert your patch. And I think that it should stay that way for 4.3.0. I'll take a look just few days, then. If PEAR is depending on the line, some people telling

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: > Yes, since it should not set in php_cli.c. > It's a lot confusing, bad thing to do with current code, > inefficient, bad default, etc. It's a very good default like Zeev explained in http://news.php.net/article.php?group=php.dev&article=89976 > > What

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

At 07:44 23/10/2002, Yasuo Ohgaki wrote: Andi Gutmans wrote: At 12:20 PM 10/23/2002 +0900, Yasuo Ohgaki wrote: Jani Taskinen wrote: Again..was this agreed upon? I suppose so. I didn't get any more objections. It's not a big deal to me but I don't understand why this should need chan

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Derick Rethans wrote: On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: Edin Kadribasic wrote: Ok. Let's agree that the current implementation is not ideal, but it works. There were already several suggestions on how this can be improved, but I don't think this is the right time to start doing it.

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

On Wednesday 23 October 2002 10:55, Yasuo Ohgaki wrote: > Edin Kadribasic wrote: > > Ok. Let's agree that the current implementation is not ideal, but it > > works. There were already several suggestions on how this can be > > improved, but I don't think this is the right time to start doing it. >

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: > Edin Kadribasic wrote: > > Ok. Let's agree that the current implementation is not ideal, but it works. > > There were already several suggestions on how this can be improved, but I > > don't think this is the right time to start doing it. > > > > So my

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Edin Kadribasic wrote: Ok. Let's agree that the current implementation is not ideal, but it works. There were already several suggestions on how this can be improved, but I don't think this is the right time to start doing it. So my proposal is that Yasuo reverts his patch until 4.3.0 is branch

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Ok. Let's agree that the current implementation is not ideal, but it works. There were already several suggestions on how this can be improved, but I don't think this is the right time to start doing it. So my proposal is that Yasuo reverts his patch until 4.3.0 is branched and then let's have

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Hartmut Holzgraefe wrote: Edin Kadribasic wrote: Doing flush after each output operation does carry a performance penalty. The following example illustrates it: php -d implicit_flush=0 -r 'for ($i=0; $i<100; $i++) echo $i;' > file This one executes about twice as fast on my machine compar

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Edin Kadribasic wrote: (B> OTOH, having implicit_flush turned on makes writing interactive command line (B> programs easier. Some programs (like pear installer) might even depend on it. (B (BIt may, but the current implementation is broken as I (Bmentioned in other mail. (B (BI don't argue

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Edin Kadribasic wrote: > Doing flush after each output operation does carry a performance penalty. The > following example illustrates it: > > php -d implicit_flush=0 -r 'for ($i=0; $i<100; $i++) echo $i;' > file > > This one executes about twice as fast on my machine compared to php with >

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

On Wednesday 23 October 2002 09:41, Edin Kadribasic wrote: (B> OTOH, having implicit_flush turned on makes writing interactive command (B> line programs easier. Some programs (like pear installer) might even depend (B> on it. (B (BThe proper way around this, as I see it, is to flush at the end

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: > BTW, you haven't reply [implicit_flush off] thread. > Usually, it means agreed. I might gave you to little > time, though. I did a few weeks ago when you was messing with it too. It's useless to repeat every discussion over and over again. See: http://

Re: [PHP-DEV] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

On Wednesday 23 October 2002 08:26, Yasuo Ohgaki wrote: (B> I thought it's obvious choice, but it seems it's not. (B> (B> Which one you prefer CLI behave like (B> (B> SH (B> (B> or (B> (B> PERL/RUBY/PYTHON (B (BIt would perhaps be easier for us to understand if you explained what problem

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: > Derick Rethans wrote: > > On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: > > > >>I suppose so. > >>I didn't get any more objections. > > > > > > You got atleast one, and that was mine. I didn't see people agree > > either. > > The line was bogus with the