Re: [PHP-DEV] emalloc() troubles

I didn't know you have cvs access. Then I'll leave the problem alone :) -- Yasuo Ohgaki Ari Pollak wrote: Again, I told you that I already fixed the problem from within PHP, but there's just one memory leak that I can't track down. On Sun, Dec 29, 2002 at 06:39:18PM +0900

Re: [PHP-DEV] emalloc() troubles

Derick Rethans wrote: On Sat, 28 Dec 2002, Yasuo Ohgaki wrote: PHP shouldn't leak memory even if output/input from/to external program differs. It seems it's a PHP problem for this matter. If you had read the thread you would have seen that the memory leak is only there in his

Re: [PHP-DEV] emalloc() troubles

u have mentioned. What kind of address format are you using? Please send me to a a short reproducing script. If I think the problem should be took care of, I'll take care of it. -- Yasuo Ohgaki Yasuo Ohgaki said: PHP shouldn't leak memory even if output/input from/to external prog

Re: [PHP-DEV] emalloc() troubles

PHP shouldn't leak memory even if output/input from/to external program differs. It seems it's a PHP problem for this matter. Are you sure your input to mail() is RFC compliant? Even if input is not RFC compliant, PHP shouldn't leak memory, though. -- Yasuo Ohgaki Ari Pollak wro

Re: [PHP-DEV] php.exe - php-cgi.exe

Sebastian Nohn wrote: (B> Jan Schneider schrieb: (B> (B>>I know this thread is ridden to death but I want to add (B>>one argument for (B>>completeness: If the cgi's name will be changed, (B>>thousands of administrators (B>>need to fix their servers. But if the cli's name will be (B>>change

Re: [PHP-DEV] php.exe - php-cgi.exe

ffect sales of Zend products, though. Just my .02 -- Yasuo Ohgaki Zeev Suraski wrote: At 19:46 09/12/2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: > > Maybe phpsh would be a good idea for the name of the CLI? It wouldn't > confuse ppl as much as php-cl

Re: [PHP-DEV] 4.2.3 mbstring patch?

Additional note, since it seems it's misleading. Yasuo Ohgaki wrote: This is one of the reason why we should *enable* mbstring by default i.e. discover sloppy patches to it. The bug was introduced between 4.2.2 and 4.2.3. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www

Re: [PHP-DEV] 4.2.3 mbstring patch?

et/diff.php/php4/ext/mbstring/mbstring.c?login=2&r1=1.48.2.14&r2=1.48.2.17&ty=u -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

ld be enough. There are problems --disable-mbstirng or --enable-mbstring=shared, but it's users problem, if it's enabled by default. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

Derick Rethans wrote: On Wed, 13 Nov 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. Do you mean array input handling bug? It&

Re: [PHP-DEV] mbstring and 4.3.0

fined symbol errors from modules depend on mbstring. PHP dies badly with it obviously. Disabling it is the same as asking for troubles. I'm 0 iff there is smart loader patch. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

Jani Taskinen wrote: Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. Do you mean array input handling bug? It's not mbstring developers' fault. -- Yasuo Ohgaki On W

Re: [PHP-DEV] mbstring and 4.3.0

. i.e. mention unsolid things, problems, etc. Bug reports are welcome. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

, we should always compile mail() function. Distributors sometimes release PHP packages (i.e. RPM) w/o mail() sometimes. -- Yasuo Ohgaki Moriyoshi "Ilia A." <[EMAIL PROTECTED]> wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany se

[PHP-DEV] Re: RfC: *_fetch_object()

I don't mind making pg_fetch_object() accept object (not class) (Boptionally and initialize field values as object's properties. (B (BHow about other db module maintainers? (B (BBTW, pg_fetch_object() accepted 3rd optional parameter (Bfor a long time. I've disabled it recently, since having 

[PHP-DEV] shared build fails. gettext and imap

Recent CVS source fails to build gettext and imap (Bas shared module with my Linux. (B (BAnyone can build them as shared module? (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List (BTo unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php4 / Makefile.global run-tests.php

Yasuo Ohgaki wrote: Derick, I've pointed out problems _WEEKS_ ago. I let you know problems _MANY_ times. Derick, be responsible with your change and opinion at least. Don't forget you're the one broke it w/o discussion first. When I add "-c php.ini-dist", there is discu

[PHP-DEV] Re: mbstring and 4.3.0

handling array inputs, but it's not mbstring developers' fault. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: cvs: php4 /ext/iconv config.m4

Moriyoshi Koizumi wrote: (B> moriyoshi Thu Oct 31 15:23:53 2002 EDT (B> (B> Modified files: (B> /php4/ext/iconv config.m4 (B> Log: (B> Fixed library capability detection behaviour. (B> # Whew! I've fixed all the known problems. (B> # And should I

Re: [PHP-DEV] Console Behavior

It's known issue... (B (B-- (BYasuo Ohgaki (B (BAdam Voigt wrote: (B> Figured it out, turns out I had actually bothered to copy the php.ini (B> from the recommended on the server it didn't work on, if I removed the (B> config file (forcing PHP to use the default options), it worked fine, (

Re: [PHP-DEV] Re: cvs: php4 / Makefile.global run-tests.php

esult, there is -c option. Please revert your patch. (And don't forget to remove double -d 'safe_mode=0') BTW, everyone agree with Derick's statement for such a simple & obvious bug fixes with CVS managed sources? -- Yasuo Ohgaki Derick Rethans wrote: On Thu, 31 Oct 2002, Yasu

[PHP-DEV] Re: cvs: php4 / Makefile.global run-tests.php

Derick Rethans wrote: (B> derickThu Oct 31 09:02:00 2002 EDT (B> (B> Modified files: (B> /php4 Makefile.global run-tests.php (B> Log: (B> Discuss first! (B (BHuh? What do you mean discuss first? (BThere is discussion and the patch is valid. (B

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

Derick Rethans wrote: On Wed, 30 Oct 2002, Yasuo Ohgaki wrote: Ilia Alshanetsky wrote: iliaa Tue Oct 29 10:22:41 2002 EDT Modified files: /php4 Makefile.global Log: Allows 'make test' to run without being harassed by open_basedir & safe_mode. This i

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

Derick Rethans wrote: On Wed, 30 Oct 2002, Yasuo Ohgaki wrote: Ilia Alshanetsky wrote: iliaa Tue Oct 29 10:22:41 2002 EDT Modified files: /php4 Makefile.global Log: Allows 'make test' to run without being harassed by open_basedir & safe_mode. This i

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

Ilia Alshanetsky wrote: (B> iliaa Tue Oct 29 10:22:41 2002 EDT (B> (B> Modified files: (B> /php4 Makefile.global (B> Log: (B> Allows 'make test' to run without being harassed by open_basedir & safe_mode. (B (BThis is just another example why we should u

[PHP-DEV] Re: [PHP-CVS] Discuss on php-dev, not on php-cvs please

Even stricter and be sure, prevent post from users like php-bugs? -- Yasuo Ohgaki Wez Furlong wrote: That would be ideal :) On Tue, 29 Oct 2002, Derick Rethans wrote: On Tue, 29 Oct 2002, Wez Furlong wrote: If you need to comment on a commit, can you please change the To/Cc line from php

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

by passing the -d option to the Command Line Interface. True, but everyone has to wait until everyone installs php/cli to standard location, such as /usr/bin/php, to have control behavior of php scripts for distributing :) I have no idea about Windows ;) -- Yasuo Ohgaki -- PHP Development Ma

[PHP-DEV] Re: setting PHP_INI_SYSTEM config. variables in VHost sections (bug20009)

Matus Fantomas Uhlar wrote: (B> Therefore I propose a change: (B> (B> PHP_INI_SYSTEM variables should be allowed to change by admin - in (B> system-wide php.ini or httpd.conf, no matter if it's VHost or not. (B (BI've never tried to use php_value/php_admin_value/php_flag/php_admin_flag (Bi

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

Derick Rethans wrote: On Tue, 29 Oct 2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: Please revert. There is no need. Derick has been changed it w/o discussion. Nice joke :) Don't you forget I've posted I'll change it? I get reply only from you, though. Old code was bo

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main streams.c

pipes, too? -- Yasuo Ohgaki --Wez. On 28/10/02, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote: Fixed bug #20110. + if (fstat(fileno(fp), &st) == -1 || !S_ISREG(st.st_mode)) { -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CLI ini selection

, use of web server ini files could be confusing and annoying. Good idea for Windows is needed, though. -- Yasuo Ohgaki Edin - Original Message - From: "Melvyn Sopacua" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 28, 2002 3:41 PM Subject: [PHP-

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

Zeev Suraski wrote: Please revert. There is no need. Derick has been changed it w/o discussion. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Implicit_flush=On by default

Zeev Suraski wrote: (B> Thank you for the detailed explanation, I'm sure everybody (B> understands it now. (B (BYou're welcome. (B (B> Let's go for the voting phase. I vote we keep PHP-CLI (B> with implicit_flush on by default. You vote against. (B (BOf course :) (BI vote -1 for it. (B

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

ault which should be turn off 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 :)

Zeev Suraski wrote: At 15:29 25/10/2002, Yasuo Ohgaki wrote: 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. Huh? It IS off by default. Of course I know it is o

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:

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

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 -

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

#x27;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 [ma

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,

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

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

;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 Ohgak

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

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] Re: [PHP-CVS] cvs: php4 / Makefile.global

s for run-tsets.php. Person, who get rid of the setting and insist specifying php.ini is not worth, even cannot find and fix problem with php.ini-recommended. Better choice is obvious, isn't? -- 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 :)

Just wanted to add little more emphasis for the reason why I (Bsay "weak reasoning". (B (BMy thoughts exactly. Defaults should work for the masses - it's not (Blike it's enforced behavior, that is irreversible. (B (B> Anyway, what kind of default we have for implicit flush in (B> php

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

Zeev Suraski wrote: (B> At 10:01 24/10/2002, Yasuo Ohgaki wrote: (B> (B>> Melvyn Sopacua wrote: (B>> (B>>> At 02:51 24-10-2002, Alan Knowles wrote: (B>>> (B>>>> Im +1 for reverting the patch - (for what it's worth) (B>>&g

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

ent/mostly useless auto flushing. Please add your vote to this article. http://news.php.net/article.php?group=php.dev&article=89995 -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

Melvyn Sopacua wrote: 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, nonethele

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

Melvyn Sopacua wrote: At 08:42 24-10-2002, Yasuo Ohgaki wrote: 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 ;) Why do you assume people learned programming? I think Rasmus has

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

s yours? That said, does it still worth to have? -- Yasuo Ohgaki Anyway Just my 2c Regards Alan It's a very _bad_ default. Fortunately, it's not released yet. That's why I'm against it strongly. IMO, flushing on every output by default is stupid setting. If you ever

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

, but it's a waste of time IMO) Therefore, I'm insisting the use of php.ini-dist many times. -- 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 RFC:CLI behave like SH or PERL/RUBY/PYTHON?)

et/article.php?group=php.dev&article=89995 This should explain the reason behind. Don't you think other language developers will make fun of the default auto flushing feature? If I were, I'll. The default is stupid and only Derick likes it, I suppose. ;) -- Yasuo Ohgaki Edin On Thu

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

[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 so

[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] RFC: CLI behave like SH or PERL/RUBY/PYTHON?

yway, PEAR will fails with or without the patch if it depends on it at least on almost all UNIX environment with current behavior. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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 star

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

the setting few days later. (It may be good idea ship pre2 with current code. Comments?) -- Yasuo Ohgaki Edin On Wednesday 23 October 2002 10:28, Yasuo Ohgaki wrote: Hartmut Holzgraefe wrote: Edin Kadribasic wrote: Doing flush after each output operation does carry a performance pe

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

e ability enable/disable implicit flushing at user's will. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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] Re: RFC: CLI behave like SH or PERL/RUBY/PYTHON?

Alan Knowles wrote: (B> To try and clarify... (B> (B> #!/usr/bin/php -q (B> (B> echo "please enter a word"; (B (Bflush(); // is needed here, since above line does not have newline. (B (B> $fh = fopen('php://stdin') (B> $s = fgets($fh,100); (B> echo "you entered $s" ; (B> (B> ?> (B

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

lly needed. If user would like to do flush, flush() function may be used (or change php.ini) -- Yasuo Ohgaki George On Wednesday, October 23, 2002, at 02:26 AM, Yasuo Ohgaki wrote: I thought it's obvious choice, but it seems it's not. Which one you prefer CLI behave like SH or PE

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

; (B> PERL/RUBY/PYTHON (B> (B> -- (B> Yasuo Ohgaki (B> (B (B (B (B-- (BPHP Development Mailing List <http://www.php.net/> (BTo unsubscribe, visit: http://www.php.net/unsub.php

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

I thought it's obvious choice, but it seems it's not. (B (BWhich one you prefer CLI behave like (B (BSH (B (Bor (B (BPERL/RUBY/PYTHON (B (B-- (BYasuo Ohgaki (B (B (B-- (BPHP Development Mailing List (BTo unsubscribe, visit: http://www.php.net/unsub.php

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

Yasuo Ohgaki wrote: Derick Rethans wrote: On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Again..was this agreed upon? 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. BTW, y

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

Derick Rethans wrote: On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Again..was this agreed upon? 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 cu

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

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 changing. Who cares what per

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

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 changing. Who cares what per

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

Jani Taskinen wrote: Again..was this agreed upon? I suppose so. I didn't get any more objections. -- Yasuo Ohgaki --Jani On Wed, 23 Oct 2002, Yasuo Ohgaki wrote: yohgaki Tue Oct 22 21:21:40 2002 EDT Modified files: /php4/sapi/cli php_cli.c Log:

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/db db.c

Jani Taskinen wrote: You propably didn't notice, but this extension is actually deprecated..you should use DBA instead. --Jani Move to PECL or remove? I think move to PECL make sense, since there should be users of db extension. -- Yasuo Ohgaki -- PHP Development Ma

Re: [PHP-DEV] short_open_tag

that comes from a SOAP developer too ;) Just wait till he starts embeding php in xsl :) (^_^) Sorry guys, but cannot resist post a smile. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] inplicit_flush off

Yasuo Ohgaki wrote: Derick Rethans wrote: On Tue, 22 Oct 2002, Yasuo Ohgaki wrote: CLI should behave like other *modern* scripting language. i.e. behave like perl, ruby, python. Currently it behaves like sh. i.e. flushing stdout for every output. Like it *should*. Please don't

Re: [PHP-DEV] inplicit_flush off

Derick Rethans wrote: On Tue, 22 Oct 2002, Yasuo Ohgaki wrote: CLI should behave like other *modern* scripting language. i.e. behave like perl, ruby, python. Currently it behaves like sh. i.e. flushing stdout for every output. Like it *should*. Please don't start again on this issue,

[PHP-DEV] inplicit_flush off

CLI should behave like other *modern* scripting (Blanguage. i.e. behave like perl, ruby, python. (B (BCurrently it behaves like sh. (Bi.e. flushing stdout for every output. (B (BComments? (B (B--- php_cli.c.~1.37.~ Wed Oct 16 06:17:34 2002 (B+++ php_cli.c Tue Oct 22 11:45:09 2002 (B@@

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

7;s a trivial change to run-tests.php. We may better to use some strange extension to avoid unwanted over writes. .src may be a good choice. Comments? -- Yasuo Ohgaki Moriyoshi Koizumi wrote: echo "=0){\$f=\$argv[\$argc];echo \"\$f\n\";\ \$b=preg_replace(\ '

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

Melvyn Sopacua wrote: However - it depends on include and relative path issues to work as expected. The problem is very frustrating, isn't? What's the plan for it? -- Yasuo Ohgaki -- 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/mbstring/tests 027.inc 027.phpt

Derick Rethans wrote: Yes, works fine here: (even with * instead of 025.*) Thing has been changed ;) I hope it's documented somewhere. -- Yasuo Ohgaki -- 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/mbstring/tests 027.inc027.phpt

Melvyn Sopacua wrote: At 22:00 10/21/2002 +0900, Yasuo Ohgaki wrote: Derick Rethans wrote: Yes, works fine here: (even with * instead of 025.*) Thing has been changed ;) I hope it's documented somewhere. Here's the docs: http://news.php.net/article.php?group=php.cvs&articl

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc

Derick Rethans wrote: On Tue, 22 Oct 2002, Yasuo Ohgaki wrote: Moriyoshi Koizumi wrote: Hi, I'm for Derick's option. Can I begin repacking each case to the single files now? IMO, including script file give us more freedom to write/execute test script. It's not efficient

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring/tests 027.inc027.phpt

hpt to something meaningful. I just followed existing test script naming convention and I don't like it, too. ;) -- Yasuo Ohgaki Moriyoshi Yasuo Ohgaki <[EMAIL PROTECTED]> wrote: Derick Rethans wrote: Yes, works fine here: (even with * instead of 025.*) Thing has been ch

[PHP-DEV] Re: #19771 - patch

Tal Peer wrote: hello, this patch tries to fix the performance issues described in bug #19771. i cannot benchmark this at the moment, so if anyone can, please do. the patch is available at http://tal.madcode.org/file.c.patch and thanks to wez :) It's not related to file(), but I found another

[PHP-DEV] Re: #19771 - patch

Yasuo Ohgaki wrote: Tal Peer wrote: hello, this patch tries to fix the performance issues described in bug #19771. i cannot benchmark this at the moment, so if anyone can, please do. the patch is available at http://tal.madcode.org/file.c.patch and thanks to wez :) Getting better, but it

[PHP-DEV] Re: #19771 - patch

Tal Peer wrote: hello, this patch tries to fix the performance issues described in bug #19771. i cannot benchmark this at the moment, so if anyone can, please do. the patch is available at http://tal.madcode.org/file.c.patch and thanks to wez :) Getting better, but it still too slow somehow...

Re: [PHP-DEV] Re: [4.3] Current critical bugs

work properly. Great! Then we can just wait their fix :) -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changing entity charset

de if internal_encoding =NULL? Is there any other concerns? -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [4.3] Current critical bugs

rious problem for serious sites. (Serious sites shouldn't use Apache2, though) -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Andi Gutmans wrote: I don't think we should add special hacks to the scanner. Soon we're going to have a zillion hacks for other XML/SGML/foobar documents. I agree. We are better to leave it as documentation issue, IMO. -- Yasuo Ohgaki Andi At 12:17 PM 10/16/2002 -0400, Ili

[PHP-DEV] Re: removing apidoc.txt

+1 It's time to do so. -- Yasuo Ohgaki Andrei Zmievski wrote: I propose we remove apidoc.txt from the tree. It is prety outdated and only promotes confusion. We have a module for API documentation and it is available online as well. -Andrei

Re: [PHP-DEV] short_open_tag

Zeev Suraski wrote: At 11:10 17/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: No, we shouldn't have. It is not a deprecated feature or a discouraged feature. If you use the *FAIRLY RARE* combination of using PHP to generate XML, you'd have to configure your PHP. If you&#

Re: [PHP-DEV] short_open_tag

Mike Hall wrote: > I would have no problem - as a user - with the removal of short_tags IF > was allowed!! Because the I use > Just to add fuel to the fire ;-) I know that. You know that Most of know that it's just another fuel ;) -- Yasuo Ohgaki -- PHP Development Mail

Re: [PHP-DEV] [PATCH] Changing entity charset

> > This is a separate issue and nothing to do with changing the behaviour of > htmlentities(). Please no automatic entity conversion for phpinfo(), it's for debugging. i.e. It does not need 100% conformance to standards to be useful... -- Yasuo Ohgaki -- PHP Development M

Re: [PHP-DEV] short_open_tag

avoided when developing applications or +; libraries that are meant for redistribution, or deployment on PHP +; servers which are not under your control, because short tags may not +; be supported on the target server. For portable, redistributable code, +; be sure not to use short tags. short

Re: [PHP-DEV] short_open_tag

Ilia A. wrote: >> We should have warned people not to use short tags years ago. > What happened in the past is in the past, lets concentrate on the future. Sure. We should. >>The best way to go is discourage use of short tag >>whenever possible, change default few years later, IMHO. >> >>Even

Re: [PHP-DEV] short_open_tag

en to language. i.e. compatibility between new and old PHP. The best way to go is discourage use of short tag whenever possible, change default few years later, IMHO. Even if we never change the default, ";?> works always w/o patch. -- Yasuo Ohgaki Ilia A. wrote: > On October 16, 2002

Re: [PHP-DEV] short_open_tag

ipts should use it. If there are new processing tags, echo "" instead of adding new PI to parser. (We never know if user use custom PI tag or not) IMHO, it's good enough work around until we have PHP6 or later. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Changing entity charset handling

ing some. BTW, we're better to have PHPAPI function returns internal encoding, rather than switch(). -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

Thanks for heads up. I made the same mistake several times even if I wrote english version of the manual page. Guessing encoding every time is stupid :) You should have wrong internal_encoding. -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

Ilia A. wrote: > Since the general consensus by the developers is not to remove the short_tags > or even disable them. Perhaps we should consider alternate solutions to this > problem. Given the buzzword popularity of XML and its slowly growing > popularity among website designers (XHTML) this

[PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

Forgot to what it's doing. Since the multibyte char sequence is too short, mbstring is failing to detect encoding correctly. In this case, we can specify encoding or modify detect order. -- Yasuo Ohgaki Yasuo Ohgaki wrote: > Ryo Takagi wrote: > >> If the line

[PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

This cannot be fixed. Check & modify your detect order by mb_detect_order(). -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: #19848 [Com]: Wrong $_REQUEST values

: > > BTW, 17958 is "no feedback". > Well, that's pretty untrue ... Wrong comment for this bug. If Apache2 SAPI still has problem with $_POST and multipart/form-data encoding, add comment to the report and reopen it. Don't forget to test with CVS version of PHP _AND_ Ap

  1   2   3   4   5   6   7   8   9   10   >