Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows

I still object because I use them every once in a while to check/debug the non TS build under Windows. I do maintain them every other year :) At 18:11 02/09/2002, Edin Kadribasic wrote: > > So why not nuke them? > >No objections here to nuking non-ts project files and workspaces on >windows.

Re: [PHP-DEV] Can't build PHP 4.2.3-RC2 on Windows

Hmm, not sure what that was, but my Linux boxes are working fine, but yes, VC's debugger is very nice :) At 20:08 02/09/2002, l0t3k wrote: >hear, hear.. >my Linux box is perpetually broken, and the Visual Studio debugger is very >nice... > >"Zeev Suraski" <[E

Re: [PHP-DEV] mbstring

At 22:52 02/09/2002, Dan Kalowsky wrote: >On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: > > > If we should reduce number of modules built by default, 1st > > module should be MySQL. Removing MySQL does not cause any > > technical problems at all. > >I'll agree to that as well. +1 on removing --with-mys

[PHP-DEV] 4.2.3RC2

4.2.3 RC2 is out - http://www.php.net/~zeev/php-4.2.3RC2.tar.gz Windows binaries will be available soon... (note - if you took the package from there or checked out the CVS tag before it was announced, you may have not gotten the real RC2). Zeev -- PHP Development Mailing List

RE: [PHP-DEV] mbstring

At 23:21 02/09/2002, James Cox wrote: >Nice to see you argue that one so eloquently... I have in the past, numerous times. I don't think I or anybody else should have to repeat themselves like broken records, you can look it up in the archives. Zeev -- PHP Development Mailing List

RE: [PHP-DEV] Default extensions (was: mbstring)

At 00:19 03/09/2002, James Cox wrote: >i still don't see why we shouldn't just disable everything by default and >write a 'default configure' script... Because other than a WFF of 'purity', it gains nothing and loses lots. Zeev -- PHP Development Mailing List To unsubscr

Re: [PHP-DEV] Re: mbstring

At 10:25 03/09/2002, [EMAIL PROTECTED] wrote: > > strlen() overloaded by mb_strlen might causes some problems because it > > is used to measure length of string and to measure length of binary > > data. So, a new function to measure string length only (or binary > > length only) will be necessary

Re: [PHP-DEV] Re: mbstring

At 11:20 03/09/2002, [EMAIL PROTECTED] wrote: >strlen -> stringlength... I think this should count the number of >characters in a string, not the binary length. It would be nice if this >function (strlen) would be transparent with mb things too, as no code >needs to be changed then. Compatibility

Re: [PHP-DEV] Re: mbstring

I'm going to argue about it (fiercely :) if/when it becomes more relevant, but not a microsecond sooner... Zeev At 11:38 03/09/2002, [EMAIL PROTECTED] wrote: >On Tue, 3 Sep 2002, Zeev Suraski wrote: > > > At 11:20 03/09/2002, [EMAIL PROTECTED] wrote: > > >strlen ->

Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.h Zend zend.h

I am, I have to make some changes to it first... At 12:51 03/09/2002, Sebastian Bergmann wrote: >Sebastian Bergmann wrote: > > sebastian Tue Sep 3 05:41:41 2002 EDT > > > > Modified files: > > /Zend zend.h > > /ZendEngine2zend.h > > Log: > > Add html_err

Re: [PHP-DEV] pread solutions needed

Why do we use pread in the first place? Zeev At 21:27 03/09/2002, Dan Kalowsky wrote: >Please read bug: > >http://bugs.php.net/bug.php?id=15983 > >As it states, currently non-i386 Linux boxen are having difficulty with >the session functionality. Mainly because of the pread/pwrite functions. >T

[PHP-DEV] Re: UTF8 support for PCRE missing from win32

You feel we can make such a change without another RC? Since we're the ones building the Win32 package, I don't worry at all about build problems, but is there any chance at all that it may break something in runtime? Zeev At 02:57 05/09/2002, Wez Furlong wrote: >I've just discovered (the har

RE: [PHP-DEV] ZendEngine2 availability

Not sure why nobody stepped in and said it, but the Engine2 is quite alive and kicking. You just have to work a bit in order to get a fairly recent version. Not so recent version: http://www.php.net/distributions/php-4.3.0-dev-zend2-alpha2.tar.gz http://www.php.net/distributions/php-4.3.0-dev-

[PHP-DEV] PHP 4.2.3 released

PHP 4.2.3 has been released. It is a maintenance release and includes a large number of fixes for the previous 4.2.2 version. 4.2.3 is a recommended upgrade for all users of PHP, and particularly Windows users. Full list of changes: - Enabled strcoll() on win32. (Markus) - Fixed possible ASCI

[PHP-DEV] [ANNOUNCE] PHP 4.2.3 released

PHP 4.2.3 has been released. It is a maintenance release and includes a large number of fixes for the previous 4.2.2 version. 4.2.3 is a recommended upgrade for all users of PHP, and particularly Windows users. Full list of changes: - Enabled strcoll() on win32. (Markus) - Fixed possible ASCI

Re: [PHP-DEV] Re: Feature Request #19411: Pre-existing classes defined WHERE?

Yep At 07:45 18/09/2002, Wez Furlong wrote: >Hi Andi, > >In the case of the following code: > >class Foo {} >class Foo {} > >PHP doesn't print a very helpful error message about the redefinition >of class Foo, particularly when the class was defined in a separate file. >The feature request is to

Re: [PHP-DEV] Thread Reading

At 12:27 19/09/2002, Yasuo Ohgaki wrote: >Dan Hardiker wrote: >>We are dealing with *idiots* here. Their CODE doesnt work, they are >>*learning* PHP, they want help on their *non-functional* code, easily, >>simply and quickly. >>We can already say "put this in a .php file then give us the URL to i

Re: [PHP-DEV] Thread Reading

There's nothing inherent about .phps that is incompatible with output buffers. Fixing this should be simple enough. At 12:52 19/09/2002, Yasuo Ohgaki wrote: >Markus Fischer wrote: >>On Thu, Sep 19, 2002 at 06:27:55PM +0900, Yasuo Ohgaki wrote : >>>Let's discourage usage of phps in the manual wh

Re: [PHP-DEV] Thread Reading

At 20:10 19/09/2002, Adam Voigt wrote: >Newbie's or people seeking help with bad security >standards, could give away the password to there SQL server, etc. >Maybe the phps parser or whatever it's called should automatically *** >out the password fields of all the db, ftp, etc. calls. I don't thi

Re: [PHP-DEV] Thread Reading

I'll try to find some time to look at it. I need to re-familiarize myself with the output buffering code at some point anyway... At 07:57 20/09/2002, Yasuo Ohgaki wrote: >Zeev Suraski wrote: >>At 12:27 19/09/2002, Yasuo Ohgaki wrote: >> >>>Dan Hardiker wrote

Re: [PHP-DEV] PHP Apache2Filter SAPI segfaults on startup

Fixed At 17:07 20/09/2002, Sebastian Bergmann wrote: >Andrei Zmievski wrote: > > Please file it as a Bug. > > Bug #19523 it is. > >-- > Sebastian Bergmann > http://sebastian-bergmann.de/ http://phpOpenTracker.de/ > > Did I help you? Consider a gift: http://wishlist.sebasti

[PHP-DEV] Reimplementing .phps

In order to fix the backwards dependencies issues, as well as simplify the implementation of phps, I suggest to ditch the existing implementation of x-httpd-php-source, and replace it with an almost-regular PHP request. Instead of reading the code from request_info.path_translated, we would g

RE: [PHP-DEV] Re: Object Overloading

At 11:42 23/09/2002, Sam Liddicott wrote: >Is there any chance I can look at some zend 5 code to see the new model, and >how it might fit with SWIG? Sure, just checkout the ZendEngine2 repository... >Also, overloaded objects are good, what do you think about overloaded >variables? (And with refe

Re: [PHP-DEV] Re: Change of cgi behaviour in 4.3.0

Just to clear any doubts - was there any real-world problem with the way things were working before this change? Zeev At 10:26 25/09/2002, Edin Kadribasic wrote: >On Wed, 25 Sep 2002 08:36:42 +0200 (CEST), Sascha Schumann wrote: > > On Wed, 25 Sep 2002, Edin Kadribasic wrote: > > > > > For some

Re: [PHP-DEV] Re: Change of cgi behaviour in 4.3.0

Ok, we need to make sure we're not creating a bigger problem with that fix. Zeev At 10:44 25/09/2002, [EMAIL PROTECTED] wrote: >On Wed, 25 Sep 2002, Zeev Suraski wrote: > > > Just to clear any doubts - was there any real-world problem with the way > > things were wor

RE: [PHP-DEV] [PATCH] include statement in php.ini file

I'm concerned that adding this directive will make lead to control structures requirements. However, it is quite useful for modular deployment; So, my suggestion is: - Don't introduce 'include' - Introduce a special 'additional_ini_directory' (name subject to change) which will be read after

RE: [PHP-DEV] [PATCH] include statement in php.ini file

At 19:27 26/09/2002, David Viner wrote: >If the term "include" is not a good keyword, I'm also happy to rework the >patch to use any keyword the group prefers. "additional_ini" sounds good to >me, and probably doesn't carry the other control-structure baggage. I don't think that additional_ini c

Re: [PHP-DEV] naming of new streams functions for 4.3

At 21:40 28/09/2002, Andrei Zmievski wrote: >I think that having them called stream_* would be more consistent with >the implementation. Making users aware of how these functions work is a >matter of documentation. I agree. Zeev -- PHP Development Mailing List To unsubsc

Re: [PHP-DEV] [PATCH] [ZE] (critical?) object comparison recursion bug

Do we really need a new #define there? I think it's quite alright to bail out in that situation as well... The check for the hashtables is fine though :) Zeev At 15:30 29/09/2002, Wez Furlong wrote: >that last patch was the wrong file, based on an earlier version :-/ >here is the correct patch

Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the

At 17:11 29/09/2002, Jean-Christian Imbeault wrote: >Pierre-Alain Joye wrote: >> >>If you need only >>constants/variable, use php_value in your php.ini/httpd.conf, or set an >>environment variable. > >I tried using php_value but it seems that it can only be used (in the >Apache httpd.conf file) t

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/zlib zlib.c /main output.c

Yasuo - this used to work in PHP 4.2 - setting zlib.output_compression = 1 should enable the default size of 4096 bytes... Did you do something that could have broken it? Zeev At 13:18 30/09/2002, Wez Furlong wrote: >wez Mon Sep 30 06:18:06 2002 EDT > > Modified files: > /ph

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

Yasuo, Implicit flush has nothing to do with the PHP-level output buffering layers. Implicit flush only means that the server-specific flush function should be called whenever output is being written using the server-specific output function. As long as you're not calling the server-specific

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

At 12:13 03/10/2002, Yasuo Ohgaki wrote: >Sebastian Bergmann wrote: >>Zeev Suraski wrote: >> >>>That's the desired behavior, please make sure you did not deviate from >>>it. >> >> He deviated from it. >> Functions like highlight

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

At 12:48 03/10/2002, Yasuo Ohgaki wrote: >Zeev Suraski wrote: >>But it does not seem as if you fixed it properly. I don't see how >>implicit flush can be at all related to output buffering. If it was, it >>should have been trivial to fix it, at a centralized place.

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

At 13:26 03/10/2002, Yasuo Ohgaki wrote: >It may not flush as user expected. It is depends on how each buffers >treat data. For instance, a handler may need 1024 bytes before output >anything. I'm not sure what you're talking about really. implicit_flush should effect ONLY what happens in the u

Re: [PHP-DEV] Re: Fixing socket reads

At 21:03 04/10/2002, Sascha Schumann wrote: > Well, my fixes were spurred because my applications broke in > the deployment phase. I am extremely surprised by the > relative low quality of the 4.3 branch. Many major bugs have > been lurking in there for months. Yep, I agree. I

Re: [PHP-DEV] [PATCH] .phps support for Apache 2

At 16:33 05/10/2002, Ilia A. wrote: >ATM this is not the case, when Zeev does make the change it is likely >it'll be >after 4.3 is released. Until such a change is made there is really no need to >restrict the functionality of Apache 2 IMHO. I actually think it's better not to introduce new .php

[PHP-DEV] Scratching the 4.3 branch

I think that given the circumstances, we should scratch the 4.3 branch and stick to the main branch for this particular release, at least until we're very close to the release itself. The vast majority of CVS traffic going on these days is bug fixes anyway, so creating the branch only makes it

Re: [PHP-DEV] Scratching the 4.3 branch

ck Rethans wrote: >On Sun, 6 Oct 2002, Sander Roobol wrote: > > On Sun, Oct 06, 2002 at 11:01:02AM +0200, Derick Rethans wrote: > > > On Sun, 6 Oct 2002, Zeev Suraski wrote: > > > > > > > I think that given the circumstances, we should scratch the 4.3 >

Re: [PHP-DEV] output buffering

I requested that Yasuo reverts his patches, repeatedly, but as he hasn't, I was forced to do it manually myself. If I screwed up while reverting the patches myself, I apologize. I'll take a look. Zeev At 08:30 07/10/2002, Derick Rethans wrote: >On Sun, 6 Oct 2002, Rasmus Lerdorf wrote: > > >

Re: [PHP-DEV] Scratching the 4.3 branch

d and Melvyn gives the thumbs up for the Sablotron stuff >then I think we are ready for RC1. > >-Rasmus > >On Sun, 6 Oct 2002, Zeev Suraski wrote: > > > I think we'd be better off waiting a bit with the php5 move. In general I > > just don't think we can pu

[PHP-DEV] Re: output buffering

It's been a while since I touched that piece of code, so I don't remember how exactly it's supposed to work. However, right now, the URL rewriting code uses output buffering, so it's not too odd that the output is being buffered. Back when I made this change, I used a 4096-byte chunk size (an

Re: [PHP-DEV] Re: output buffering

At 10:55 07/10/2002, Yasuo Ohgaki wrote: >As I said before, I don't touch any of chunk size related code. >You've removed all applicable lines regarding to implicit flush >thing. No implicit flush please. Enough. It's over. Seriously, please, it's really getting on my nerves already :) [*] >

[PHP-DEV] Re: output buffering

At 12:24 07/10/2002, Sascha Schumann wrote: > > A couple of questions for clarity: > > > > (a) Does this work properly with PHP 4.2? > > There is an even weirder bug, at least in the 4.2.3/CGI case > (the session output handler gets called after the request > shutdown which already di

[PHP-DEV] Layout issues

Guys, Please make sure you're all well familiar with CODING_STANDARDS, most notably [2] and [3] in the syntax and indentation section. Thanks, Zeev [2] Use K&R-style. Of course, we can't and don't want to force anybody to use a style he or she is not used to, but, at the very

Re: [PHP-DEV] Re: output buffering

At 14:51 07/10/2002, Yasuo Ohgaki wrote: >Zeev Suraski wrote: >>The least you should do is ask either Sascha or me how come it uses >>chunked buffering, and whether it's not a bug. You would have gotten a >>pretty clear response saying that it fully supports chunked

Re: [PHP-DEV] 4.3 plans

Sounds good to me. At 17:09 07/10/2002, Andrei Zmievski wrote: >I think the general consensus is that PHP tree is not ready for >branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from >HEAD on Thursday, so that QA team (or what's left of it) and everyone >else can test it. Subse

Re: [PHP-DEV] Re: output buffering

At 17:53 07/10/2002, David Reid wrote: >Agreed, it's only common courtesy. At minimum. When we're dealing with the core of an application as popular as PHP, it's also an issue of responsibility. Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php

[PHP-DEV] Re: output buffering

Can you see if calling php_end_ob_buffers() in the session deactivate function, in case BG(url_adapt_state_ex).active is true, solves this problems? Zeev At 12:24 07/10/2002, Sascha Schumann wrote: > > A couple of questions for clarity: > > > > (a) Does this work properly with PHP 4.2? > >

Re: [PHP-DEV] Segfaults in Zend

What are you doing in order to get it to crash? At 18:20 07/10/2002, Jan Schneider wrote: >Hi, > >I currently get following segfaults: > >httpd logs: > >[Mon Oct 7 17:17:45 2002] [notice] child pid 19460 exit signal >Segmentation fault (11) >FATAL: emalloc(): Unable to allocate 1515870812 byt

Re: [PHP-DEV] Segfaults in Zend

Try reducing IMP to the smallest possible script that still reproduces the problem (crashes). That will give us something to go on. Chances are it's not a crash in the engine. At 18:37 07/10/2002, Jan Schneider wrote: >Zeev Suraski wrote: > >>What are you doing in order t

Re: [PHP-DEV] Re: output buffering

At 18:43 07/10/2002, Sascha Schumann wrote: >On Mon, 7 Oct 2002, Zeev Suraski wrote: > > > Can you see if calling php_end_ob_buffers() in the session deactivate > > function, in case BG(url_adapt_state_ex).active is true, solves this > problems? > > Note the condit

Re: [PHP-DEV] 4.3 plans

Shush. They already think we're a single schizophrenic person, don't add more wood to the fire :) At 23:32 07/10/2002, Andi Gutmans wrote: >Wow. Zeev and I used the *exact* same sentence. Scary... > >Andi > >At 05:19 PM 10/7/2002 +0300, Zeev Suraski wrote: >>Soun

Re: [PHP-DEV] Re: output buffering

hor(s) about it, CCing php-dev. Worst case - you'll ask a bit more than necessary, but that's much better than not asking enough. Let's look forward now... Zeev At 03:32 08/10/2002, Yasuo Ohgaki wrote: >Zeev Suraski wrote: >>Really? Yasuo, people have been requesting that we

Re: [PHP-DEV] session_register warnings

FWIW, I didn't manage to understand what the problem was with the codebase before the patch. Sascha - can you explain it? I tend to agree with Rasmus about this change being a not-so-good idea, but maybe we're just not aware of the problems that existed before the patch. Zeev At 19:09 09/10/

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

My guesstimate - lots of people use it. So, I'm -1 on breaking BC... Zeev At 23:05 09/10/2002, Andi Gutmans wrote: >I haven't :) >Anyway, I understand your reasoning. I just felt that lately too many >things have been breaking around us. >I'm cc'ing php-dev as that is a bigger forum. Have any

Re: [PHP-DEV] Re: session_register warnings

Sascha, What I, at least, fail to understand is the answer to Rasmus' initial question(s): - Are we going to break compatibility? If not, then why are we spitting out this error by default? Given what I've seen here in the last few days, I think it's fair to say that this notice will cause q

Re: [PHP-DEV] Re: session_register warnings

At 11:06 13/10/2002, Sascha Schumann wrote: >On Sun, 13 Oct 2002, Zeev Suraski wrote: > > > Sascha, > > > > What I, at least, fail to understand is the answer to Rasmus' initial > > question(s): > > - Are we going to break compatibility? If not, then

Re: [PHP-DEV] short_open_tag

Strong opposition for changing this default from my end, if only for the fact I'll be scared to show up in any PHP conference, fearing the wrath of angered users. Also see numerous past posts from me, Andi and others about why changing a number in the version doesn't give us a "carte blanche"

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

At 16:26 15/10/2002, Andrei Zmievski wrote: >Summary: Copy of array is affected by reference >URL: http://bugs.php.net/bug.php?id=15025 If you keep that one on the critical list, then 4.3.0 will remain a philosophical concept :) >Summary: Under Apache, register_shutdown_function() broke bet

Re: [PHP-DEV] short_open_tag

At 17:52 15/10/2002, Dan Hardiker wrote: >I am still +1 on some how getting away from short_open_tag support, if >nothing else, to encourage better coding practices (just as we did with >turning register_globals off by default). Except unless you mix PHP and XML, this change is meaningless, and i

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

At 21:14 15/10/2002, Joseph Tate wrote: >Throw me a bone then. What is the suggested way to offer php developers >the opportunity to run code after the connection has been closed? I think I mentioned this as well; IMHO, if we want to create the ability for users under Apache/UNIX to run stuff

Re: [PHP-DEV] short_open_tag

At 04:29 17/10/2002, .: B i g D o g :. wrote: >IMHO, i think that short tags should be taken out of php and just use >the http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

At 05:11 17/10/2002, Yasuo Ohgaki wrote: >Ilia A. wrote: >>>Isn't BIG caution for short_open_tag=Off while having short_open_tag=On >>>enough for now? Something like; >> >>Nope, please consider a hosting enviroment where an average user does not >>even have access to the php.ini file. In fact, mo

Re: [PHP-DEV] short_open_tag

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] 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] short_open_tag

At 07:40 18/10/2002, Andi Gutmans wrote: At 01:09 AM 10/18/2002 +0200, Zeev Suraski wrote: At 18:49 17/10/2002, Rasmus Lerdorf wrote: has whitespace. And I personally think it's a bit pushing it. How likely is it for someone to have a function called xml(), and then call it without a

Re: [PHP-DEV] short_open_tag

At 18:49 17/10/2002, Rasmus Lerdorf wrote: has whitespace. And I personally think it's a bit pushing it. How likely is it for someone to have a function called xml(), and then call it without a space from the Zeev -- PHP Development Mailing List To unsubscribe, visi

Re: [PHP-DEV] short_open_tag

At 10:32 18/10/2002, Andi Gutmans wrote: Why for a couple of years? Oh because we might end up finding out it wasn't such a good idea after all? :) No, because in a couple of years maybe Well anyway, as far as I'm concerned, it's not such a big deal either way and it's always fun to be able t

Re: [PHP-DEV] short_open_tag

Well, I differ with you on that. I don't think there's anything in the same class as Zeev At 18:08 17/10/2002, 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. Andi At 12:17 PM 10/16/2

Re: [PHP-DEV] short_open_tag

At 07:33 22/10/2002, Terence Kearns wrote: Agreed. If short tags were disabled in v5, then there would be no such need for a hack like this. Right, we might as well switch to Wake up people, not only are we not going to abandon short tags, we're also not going to change their defaults. We'

Re: [PHP-DEV] short_open_tag

At 09:36 22/10/2002, Terence Kearns wrote: Andi Gutmans wrote: At 03:33 PM 10/22/2002 +1000, Terence Kearns wrote: Agreed. If short tags were disabled in v5, then there would be no such need for a hack like this. They won't be disabled. They won't be disabled. They won't be disabled. They

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?

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]

I don't think that matters that much really. Even if it's 2%, and not 12% or 50%, we're still talking about billions of lines of code... Let's, please, give it a rest. Zeev At 11:13 24/10/2002, Kristian Koehntopp wrote: We have heard a lot of anecdotal evidence about the usage of other metho

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

This has nothing to do with academical correctness. Flushing or not flushing is not a matter of right or wrong, it's a matter of choice. There's one 'real language' that does automatic flushing, it's called PHP, and it's going to stay that way. Why other languages chose not to do it (maybe th

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

At 10:01 24/10/2002, Yasuo Ohgaki wrote: Melvyn Sopacua wrote: At 02:51 24-10-2002, 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 wond

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

At 12:23 24/10/2002, Yasuo Ohgaki wrote: function prompt($prefix) { echo $prefix; flush(); } is _TRIVIAL_ to write. People should have this kind of function instead of enabling inefficient implicit flushing since it's more efficient and reliable. You print something, it doesn't print out. Ho

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

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

t votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: 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 I

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

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. BTW, I don't object to have output_buffering=Off by default

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

At 18:37 27/10/2002, George Schlossnagle wrote: +1 unless it is set as an INI_ANY, then +0. It's already INI_ANY... -- 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 :)

imply not buying into your reasoning, as reasonable as it may sound to you personally. Please revert. Zeev At 04:21 28/10/2002, Ilia A. wrote: +1 to keep PHP-CLI with implicit_flush. Ilia On October 27, 2002 09:05 pm, Zeev Suraski wrote: > Thank you for the detailed explanation, I'm s

Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)

At 07:35 28/10/2002, Thies C. Arntzen wrote: On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote: > TCA>> but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks > TCA>> against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor > TCA>> anytime before init_execut

Re: [PHP-DEV] setting PHP_INI_SYSTEM config. variables in VHostsections (bug 20009)

It should work fine, as long as you use the php_admin directives. At 21:50 20/10/2002, Matus "fantomas" Uhlar wrote: Hello, I found out that it is not possible with current php stable version (4.2.3) to define some configuration variables per virtual host - e.g. upload_tmp_dir. The upload_tmp_d

Re: [PHP-DEV] html_error related to phpinfo() output

Shouldn't there be different settings? People may very well want html errors off, but still keep the rest of PHP 'web enabled'... At 08:58 29/10/2002, Derick Rethans wrote: On Tue, 29 Oct 2002, Steve Alberty wrote: > why result the functions phpinfo() and phpcredits() as plain text > when i set

Re: [PHP-DEV] hebrew patch for jewish calendar

to make things clearer English would have been much better... otiyot == latters techidot == singles asarot == tens meot == hundreds In short, there's a weight for every letter in the alphabet, and numbers are generated from a combination of letters. At 23:35 30/10/2002, moshe doron wrote: > mos

Re: [PHP-DEV] hebrew patch for jewish calendar

Sorry for the Engrish - latters == letters At 00:53 31/10/2002, Zeev Suraski wrote: to make things clearer English would have been much better... otiyot == latters techidot == singles asarot == tens meot == hundreds In short, there's a weight for every letter in the alphabet, and numbers

Re: [PHP-DEV] [PATCH] Redirect on Error

They should definitely be in the C code. Look at gettext as a pretty good example. Taking them out is seriously inferior to having them in - it makes maintenance much tougher, and PHP itself less robust. Suddenly, if you don't have some external file, errors would show up as stupid error numb

Re: [PHP-DEV] [PATCH] Redirect on Error

At 13:05 26/11/2002, Maxim Maletsky wrote: Derick, that's the price of usability. Open Source always suffered from that, and forever will if the usability will not be considered as one of the main benefits, especially for a programming language as PHP. I agree on 110% that it will be harder to

Re: [PHP-DEV] [PATCH] Redirect on Error

At 13:11 26/11/2002, Maxim Maletsky wrote: That sounds selfish of us, Derick. No, it doesn't. If we're going to attempt at doing something that has a high risk of screwing up PHP and slow down its QA and support, we should be mature enough to know our limits. If we don't, the ones that would

[PHP-DEV] Re: [Zend Engine 2] RFC: Conversion patch

At 07:27 27/11/2002, Andi Gutmans wrote: At 04:41 PM 11/26/2002 -0500, Daniel Cowgill wrote: So why do the conversion in arithmetic? This seems bizarrely inconsistent to me: I think it's reasonable to expect those expressions to return the same value. Hmm, this is definitely interesting. The

RE: [PHP-DEV] Error Codes, Langs, etc

At 02:27 27/11/2002, Stig S. Bakken wrote: Let's try being realistic, and focus on the quick wins first, such as good error codes. Go Stig. Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Reusing PHP string value pointers

At 02:50 28/11/2002, Marshall A. Greenblatt wrote: Apologies in advance if this is the wrong mailing list. Please direct me to a more appropriate mailing list if there is one :-) When a PHP string variable is changed via a PHP script, such as: $foo = 'new value'; what happens to the `value.st

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c

How does this patch possibly fix something in this magnitude? It doesn't appear to do anything crucial at all, or do these variables have some far-reaching indirect effect? Zeev At 07:45 02/12/2002, Shane Caraveo wrote: It's not a matter of php cgi just having a couple bugs, it was completely

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

Why not just use BEGIN_EXTERN_C() and END_EXTERN_C()? Zeev At 17:18 02/12/2002, J Smith wrote: Taking a few comments into consideration, here's a new patch for adding C++ code-generating abilities to ext_skel. The new patch doesn't use a separate skeleton.cpp file. Instead, it adds some lines l

Re: [PHP-DEV] [PATCH] New changes to ext_skel for C++

would be possible, but in the first instance, BEGIN/END_EXTERN_C() aren't defined yet, as they're in zend.h. The compiler would totally barf. I had used BEGIN/END_EXTERN_C() in the first patch I sent out, but decided to use one or the other in this one for the sake of consistency. J

Re: [PHP-DEV] register_shutdown_function => register_offline_function

Brian, BC is an issue, always, but as the person who wrote both the original version and the fix, I can tell you that the original behavior was not intended to begin with, and because it couldn't be duplicated on any other server than Apache, it was changed to both reflect the intended behavior

[PHP-DEV] Re: Latest ZE2 changes

At 17:02 07/12/2002, Marcus Börger wrote: Hi Zeev, I have changed the test files and encountered some problems with the way you modified my patch: 1) private_002.phpt fails with 004- Fatal error: Call to private method pass::show() from context 'fail' in %s on line %d 004+ Fatal error: Call t

Re: [PHP-DEV] Re: Latest ZE2 changes

At 15:44 08/12/2002, Marcus Börger wrote: Looking into deep reveals that we must disallow overriding privates now. That way the test private_007.phpt is illegal and all current tests i developed would pass (visibility tests are suspended of cause). How do you arrive in that conclusion? The algo

<    1   2   3   4   5   6   7   8   9   10   >