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 M

Re: [PHP-DEV] Re: mbstring

gt; length only) will be necessary. > >Sure, I don't think that will be a problem. I do. strlen() should go on returning the binary length, breaking that is really a bad idea. We can introduce a new function altogether that returns the 'calculated' MB aware length, that won'

Re: [PHP-DEV] Re: mbstring

discussions we can fight over before we have to get around to this :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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 prea

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

RE: [PHP-DEV] ZendEngine2 availability

it. Once that's done - build, and you'd have a ZE2-powered version. It's pretty much beta quality at this stage. Zeev At 02:29 05/09/2002, Tyson Lloyd Thwaites wrote: >Oh, ok. Sigh! I'll stick with the old engine then. > >Thanks > >Tyson Lloyd Thwaites > &g

[PHP-DEV] PHP 4.2.3 released

ASCII control char injection in mail(). (Stefan Esser) - Fixed a potential crash bug in import_request_variables() (Zeev) - Fixed several problems with directory functions on Windows. (Steph) - Fixed xbithack bug in Apache module. (Rasmus) - Fixed a bug that prevented touch() from working on various

[PHP-DEV] [ANNOUNCE] PHP 4.2.3 released

ASCII control char injection in mail(). (Stefan Esser) - Fixed a potential crash bug in import_request_variables() (Zeev) - Fixed several problems with directory functions on Windows. (Steph) - Fixed xbithack bug in Apache module. (Rasmus) - Fixed a bug that prevented touch() from working on various

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

tp://whatever.com/script.php so I can see the error in action - I >>tell them "ok, rename it to phps". Voila - I get the source. >>THIS is where phps is SO useful. > >I'm not insisting we should remove phps, but discourage use of it :) Can you explain w

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

, etc. calls. I don't think that this argument holds too much water. You have to intentionally create .phps symlinks in order for them to be exposed. It's not any different from being able to create a .txt symlink to it. Anything else? Zeev -- PHP Development Mailing List <

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

generate a buffer that contains something along the lines of the following code: where %s is request_info.path_translated, and execute it using eval_string(). It would greatly simplify the implementation and make it much more easy to change/maintain. Comments? Zeev -- PHP Development

RE: [PHP-DEV] Re: Object Overloading

s? (And with references these might just become overloaded zvals... >Hmm...) Anyway... Our variables have no type, so overloading can only be done on the value level. We don't want to overload any non-OO syntax. Zeev -- PHP Development Mailing List <http://www.php.net/> T

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: >

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

to change) which will be read after php.ini loads up. Only one (at most) such directory, full path required. This gives you (as far as I can tell) the modular deployment features, but won't make people beg for 'if'. Thoughts? Zeev At 00:50 26/09/2002, Rasmus Lerdorf wrote: >

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

ures. It becomes a feature of PHP, instead of a feature of the php.ini syntax. It's something we can even set up during 'make install' with a default being /usr/local/etc/additional_php_inis or something like that. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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 <http://www.

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

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

(in the >Apache httpd.conf file) to set *real* php config variables. That's correct. It only works with 'tracked' INI directives, ones registered in the INI subsystem. Zeev -- 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/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 > > Modif

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

n no way should enabling implicit-flush change the output of an application, it must not interfere with the programmable output buffering layers of PHP. That's the desired behavior, please make sure you did not deviate from it... Thanks, Zeev At 05:48 03/10/2002, Yasuo Ohgaki wrote:

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

e and dandy, except this feature is very useful, so removing it is not ok with me at all. Let's keep it as it was intended. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

I agree. I think that the current 4.3 branch is extremely unstable. We're looking at a pretty long release cycle here :I Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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 bette

[PHP-DEV] Scratching the 4.3 branch

y worried about sync problems with 4.3. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scratching the 4.3 branch

I think we'd be better off waiting a bit with the php5 move. In general I just don't think we can push a successful release while we continue developing. If we concentrate on getting 4.3 out the door within a month, we can then concentrate on php5. Zeev At 13:33 06/10/2002, Deri

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

Re: [PHP-DEV] Scratching the 4.3 branch

. Given the fact that bug fixing is going to be much more popular than adding new features, it's the logical thing to do, IMHO. Zeev At 19:18 06/10/2002, Rasmus Lerdorf wrote: >I don't think we can just not provide some place for people to work on new >code. We have way too many exten

[PHP-DEV] Re: output buffering

it's supposed to do (i.e., yields the right output)? Zeev At 06:02 07/10/2002, Sascha Schumann wrote: > Hi, > > the recent changes in the output buf layer are causing PHP to > buffer data too aggressively. > > The test case outputs two lines of HTML

Re: [PHP-DEV] Re: output buffering

buffering, and whether it's not a bug. You would have gotten a pretty clear response saying that it fully supports chunked buffering. Zeev [*] The reason I'm edgy is that on top of the public discussion about implicit flush, there was also a fairly long email exchange between Yasuo

[PHP-DEV] Re: output buffering

activated before this output is flushed, we're in trouble... I'll take a look at it. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

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 <http://www.php.net/> To

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

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 1

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

Re: [PHP-DEV] Re: session_register warnings

do plan to break compatibility, it's best if we follow the lead of allow_call_time_pass_reference, and default to having this warning off. Zeev At 21:36 11/10/2002, Sascha Schumann wrote: > > This is the exact same code run twice. It works exactly the same both > > times. Where i

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

t;carte blanche" to break compatibility. Compatibility breakage is cumulative - the more you break, the harder it is to adapt. Zeev At 10:36 15/10/2002, Dan Hardiker wrote: > >>> Thousands of programmers use short tags in their scripts, but only > >>> hundreds c

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

n() broke between 4.0.x >to 4.1.x >URL: http://bugs.php.net/bug.php?id=15209 I stated my stand on this, I believe that the 4.1.0 behavior is the more correct one. I have to go now, but I'll look at the rest of relevant bugs later today. Zeev -- PHP Development Mailing List <

Re: [PHP-DEV] short_open_tag

urned off already. Does this make sense to you? I sure hope not :) Regardless of the security risk (which is quite grave), there's no real benefit to changing the default, and plenty of drawbacks. Nay nay nay. Zeev -- PHP Development Mailing List <http://www.php.net/> To uns

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

jection to adding the Apache specific equivalent to 4.3. As a matter of fact, if it solves a problem - I'm quite for it. I hope this bone is meaty enough :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

f you use the *FAIRLY RARE* combination of using PHP to generate XML, you'd have to configure your PHP. If you're with the vast majority of the population and couldn't care less about writing XML-embedded scripts, you enjoy a working short tag. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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(",&q

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 <http://www.php.net/> To

Re: [PHP-DEV] short_open_tag

lways fun to be able to say "I told you so" so I'll retire from this discussion. Admittedly there are good points to both sides. I can only argue with myself so much, eh? :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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. And

Re: [PHP-DEV] short_open_tag

aults. We'd appreciate it if people stopped wasting the time of people on this list with this stale discussion. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

wever, is the fact that everyone's already fed up with this stale discussion. Therefore, please stop. Thank you. Zeev -- 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 /sapi/cli php_cli.c

odern and successful scripting language named PHP is wrong. I personally find it not-useful to have to flush() all the time if I don't print out newlines, so having implicit_flush turned on by default in CLI doesn't sound like a very bad thing. Unless you can prove otherwise, please re

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

so that it can also be done with ini_set(). Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

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

ges chose not to do it (maybe they don't have the facilities to do it?) is beside the point and not all that interesting. Thank you. Zeev At 09:17 24/10/2002, 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 pr

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

ew? It's 3 times more than the votes in favour, and now it's 4 times more. Too weak? That's your opinion, and it doesn't weigh more than others'. Zeev -- 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 :)

not only don't know about the existence of flush(), but also don't know why it's even necessary. Zeev -- 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

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 :)

s exposure when compraed to php.ini-dist. Zeev -- 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 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)

ecutor a bit "up"? Probably not. Can you simply fix the OnChange callback? :) NULL up the ASSERTG(callback) on time? Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

nk the cons outweigh the pros. If we were, however, to ever internationalize them - it would have to be optional, and with the full hardcoded error messages inside the code remaining intact. Zeev At 13:01 26/11/2002, Maxim Maletsky wrote: I apologize for shouting, didn't mean to be offensi

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

r messages, but my guess is that they won't be the majority of users. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

, the ones that would suffer eventually would actually be the users. Knowing your limits is a virtue, and taking unnecessary risks, while may seem noble, will often lead to much worse results. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

Getting it to work with a few extra cases doesn't hurt us in any way that I can tell. Standard disclaimers apply - I might be missing something. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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 <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

ens to the `value.str.val' pointer internally? Is it possible to have the new value assigned to the same `value.str.val' pointer that the variable is currently using instead of having that pointer replaced by a pointer to the new value? No, it's not possible (not in a reliable wa

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

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

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

Why do we need an extern c before php.h? The relevant API functions in php.h should be extern "c"d in my opinion, wrapping php.h up in extern "c" is not very clean. Zeev At 17:32 02/12/2002, J Smith wrote: For the second instance where extern "C" is used, that

Re: [PHP-DEV] register_shutdown_function => register_offline_function

ended behavior, and allow us to implement it properly on all web servers. Zeev At 17:56 05/12/2002, Brian Moon wrote: Has the new function been created yet and if not when? We have just spent 2 weeks investigating why our pages started dragging to find out that register_shutdown_function is BROKE. I

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

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

algorithm was designed to fully support it. Running private_007 also appears to be working for me (there was a buglet in the parser with static+access level, but if you remove the statics and/or update to the latest CVS, you can see that it's working fine...) Zeev -- PHP Development Mailing

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

same thing on different machine targets. And Remeber: you can use the win executable by calling 'php' without '.exe' as well. I agree with Marcus. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

I. In most senses, it's much more PHP than the CLI is. Even though the old version was being used as a shell, it was still quite clear that it is the CGI version. And it is quite clear that the CLI version is the one that's new... Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

At 18:57 09/12/2002, John Coggeshall wrote: > >Maybe phpsh would be a good idea for the name of the CLI? It wouldn't >confuse ppl as much as php-cli > Why when I look at "phpsh" I think "Sushi"... Is that good or bad? :) -- PHP Development Mailing List To unsubscribe, vi

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

n sapi/cgi instead of where it was. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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

we even considering this rename? Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

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