Re: [PHP-DEV] Non threadsafe Windows build

At 19:24 11/01/2003, Andi Gutmans wrote: At 07:13 AM 1/11/2003 +0100, Sebastian Bergmann wrote: The project file(s) for the non threadsafe Windows build are out of sync with the thread safe one(s). IIRC, there was already some discussion to ditch the non threadsafe version. That way we d

RE: [PHP-DEV] PHP4 + PHP5

At 08:26 14/01/2003, Derick Rethans wrote: A patch for naming it libphp5 or a patch that enables them to work together in the same webserver? The latter is quite hard and 'cookie a patch' for that will almost certainly not work. Wouldn't --enable-versioning work just fine? Zeev -- PHP Develop

RE: [PHP-DEV] PHP4 + PHP5

At 12:30 14/01/2003, Derick Rethans wrote: On Tue, 14 Jan 2003, Zeev Suraski wrote: > At 08:26 14/01/2003, Derick Rethans wrote: > >A patch for naming it libphp5 or a patch that enables them to work > >together in the same webserver? The latter is quite hard and 'cookie a >

RE: [PHP-DEV] PHP4 + PHP5

At 12:40 14/01/2003, Derick Rethans wrote: On Tue, 14 Jan 2003, Zeev Suraski wrote: > At 12:30 14/01/2003, Derick Rethans wrote: > > > Also, why would we need it for php4/php5? > > Because it'll probably not be 100.0% downwards compatible... hmm, I think a nice thing to

Re: [PHP-DEV] request data filter

At 02:52 16/01/2003, Rasmus Lerdorf wrote: In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler h

Re: [PHP-DEV] calling php__LINE__ & php__FILE__ in a (zif) function

zend_get_executed_filename() and zend_get_executed_lineno() should work. Zeev At 14:01 20/01/2003, Johannes G. Arlt wrote: Hi all, For a (extension)-function (zif), is there a way to get __LINE__ and __FILE__ from the current php-script. I neet the php__LINE__ and php__FILE__ in my own ext.-fu

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

At 12:41 23/01/2003, Piotr Sobolewski wrote: Can somebody tell me approximately when it will happen? 3 months? Year? If everything works properly, it should be out before the end of the year, hopefully around Q3. We'll start to release betas in the very near future (weeks), so you'd be able to

RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

Rasmus, The whole point of the list was to avoid threads like this letter is going to spawn. Let's stop it here, please. John - if you feel you belong in php5-dev(*) and want to actively participate in the discussions, we'll add you. The point of php5-dev was to create a working group for ge

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

Ok, I can't be bothered to fight a mailing list that was supposed to trim down endless discussions. I'm not the one that asked for the list, but I definitely supported it, as unlike most of the members on this list, I remember the pre-v4 days, and what kind of mountains we had to push in order

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

At 00:08 24/01/2003, Rasmus Lerdorf wrote: You should have learned this by now. Perception and warm fuzzies is an extremely important part of a large open source project that relies heavily on a large number of volunteers. Messing with that is playing with fire. I believe we can get work done o

Re: [PHP-DEV] win32 builtin zlib

At 19:59 25/01/2003, Friedhelm Betz wrote: Hi, I rewrote the part in the phpdoc manual about building on windows. zlib is builtin with 4.3.0 but the shipped Workspace for VC++ relies on a precompilded external zlib.lib. Therefore building on win32, out of the box, is not possible without downloa

Re: [PHP-DEV] win32 builtin zlib

At 00:25 26/01/2003, Friedhelm Betz wrote: Saturday, January 25, 2003, Zeev Suraski wrote: >>1.) Are there future plans to include the zlib sources? > No. zlib is included in a similar way to the way we include > bindlib_w32. It's in a different repository on cvs.php.net, tha

Re: [PHP-DEV] RFE: trigger_error()

At 14:29 27/01/2003, Sebastian Bergmann wrote: Right now if one uses trigger_error() to trigger an error the line number that gets displayed is that of the trigger_error() line. Would it be possible to add additional parameters to trigger_error() to pass a filename and a line number to it

[PHP-DEV] Re: Register Shutdown Function for Apache

Joseph, Your latest patch seems to be in the right direction (admittedly I haven't reviewed it until now). A couple of random points: - It sounds dangerous to me to move php_request_shutdown() to be called from Apache's shutdown without further inspection. At least one thing comes to mind -

Re: [PHP-DEV] Segmention fault in HEAD (zend_hash_find)

Fixed. At 08:04 28/01/2003, Magnus Määttä wrote: Hi! This code produces this segfault under HEAD. bt ( for the whole bt: http://novell.stoldgods.nu/~magnus/bt ): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 31900)] 0x0825350c in zend_hash_find (ht=0x8

RE: [PHP-DEV] Re: Register Shutdown Function for Apache

At 19:54 28/01/2003, Joseph Tate wrote: Then, could we add a sapi_flush()/ob_flush() call at the end of apache_php_module_main after calling the normal register_shutdown_functions? Yeah, something along these lines. What else might have problems? Might is a powerful word :) Zeev -- PHP De

Re: [PHP-DEV] Segmention fault when doing make install

Fixed. At 01:44 28/01/2003, Magnus Määttä wrote: This is in current head. (cd .libs && rm -f libphp4.la && ln -s ../libphp4.la libphp4.la) Installing PHP SAPI module Installing shared extensions: /usr/local/www/php5mincli/lib/php/extensions/debug-non-zts-20020429/ Installing PEAR environment:

Re: [PHP-DEV] Re: Configure-System on Solaris

I don't think we can rely on GNU grep being installed though... At 17:29 04/02/2003, J Smith wrote: GNU grep should work. Just make sure /usr/local/bin comes before /bin in your $PATH. J Sebastian Nohn wrote: > Latest CVS (PHP5-dev) on Solaris: > > Configuring TSRM > checking for stdarg.h...

Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions

At 13:36 06/02/2003, moshe doron wrote: b. sunrise() c. sunset() Hrm, what are these functions? Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version

At 01:37 07/01/2003, Joseph Tate wrote: Well, according to my highly technical methods of deduction (fprintf(stderr, "Inside sapi_shutdown");) sapi_shutdown is never called when serving a PHP request when served using mod4_php under Apache. This is because the shutdown_wrapper never gets initial

Re: [PHP-DEV] zend_timeout and the SIGPROF signal

On timeout, the engine will call zend_bailout(), which performs a longjmp(). It does unwind the stack, but since we're dealing with C and not C++ and there are no destructors, it's your responsibility to clean after yourself. You can do it by properly registering your resources with PHP's inf

Re: [PHP-DEV] zend_timeout and the SIGPROF signal

At 17:05 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - > On timeout, the engine will call zend_bailout(), which performs a > longjmp(). It does unwind the stack, but since we're dealing with > C and > not C++ and there are no destructors, it's your responsibility to > clean >

RE: [PHP-DEV] zend_timeout and the SIGPROF signal

At 17:20 20/02/2003, Jeremy Mullin wrote: Don't call malloc? Wow, that puts some serious restrictions on what an external library can do. :) In the code that you control, obviously. Couldn't drivers be required to implement something like SQLCancel in ODBC? A mechanism that lets the driver p

Re: [PHP-DEV] zend_timeout and the SIGPROF signal

At 16:58 20/02/2003, [EMAIL PROTECTED] wrote: > I have a question in regards to page timeouts and how the initial > I've noticed if a query takes longer than the default 30 seconds to > execute, php returns a timeout message to the user. From what I can > tell, php uses the SIGPROF signal to stop

Re: [PHP-DEV] zend_timeout and the SIGPROF signal

At 17:38 20/02/2003, [EMAIL PROTECTED] wrote: - Original Message - > I looked into the bug report, and it is true that > BLOCK_INTERRUPTIONS > should indeed block SIGPROF. I'll fix this in the weekend. I'm not sure if after unblocking interruptions PHP will get SIGPROF ... it could cause

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

At 17:50 28/02/2003, Sascha Schumann wrote: I think that simply adding OnUpdateLong and deprecating OnUpdateInt is fine while retaining its current semantics. +1 Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Tie'ing variables

I wanted to do this for some time, but until recently, it wasn't very feasible, because the order of registration could be designated by the user (gpc_order, variables_order, etc.). Now that register_globals is off by default, and that we have the auto-globals, it's much more feasible. I imple

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h

. If&when _SERVER is created, it will attempt to copy them. Thoughts? Zeev At 17:15 02/03/2003, Marcus Börger wrote: At 11:19 02.03.2003, Zeev Suraski wrote: zeevSun Mar 2 05:19:17 2003 EDT Log: Add JIT initialization for _SERVER and _ENV (it's less important for th

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h

At 17:56 02/03/2003, Marcus Börger wrote: At 16:38 02.03.2003, Zeev Suraski wrote: Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that? CLI overwrites "register_argc_argv": zend_alter_ini_entry("registe

Re: [PHP-DEV] Language Auto Detection / www.php.net

I agree, this auto language detection is quite annoying... Zeev At 11:05 10/03/2003, Stefan Esser wrote: Good morning, is there any chance that we can revert this annoying feature? The translated documentation is always behind and partly lacks important information from the english version. I wa

Re: [PHP-DEV] [WARNING] Release process for 4.3.2 starts RSN..

At 18:17 09/03/2003, Derick Rethans wrote: Hello, I guess nobody is interested in fixing this? Then I guess we won't get 4.3.2 ever. 4.3.2 will be coming out soon either way, there's really no need for this kind of talk. I'll see if I can get some of these fixed, but we should get ready to relea

Re: [PHP-DEV] Segfault

Fixed! Thanks, Zeev At 18:17 11/03/2003, Andrei Zmievski wrote: With the latest ZE2: class Bar { function boo() { ::zoo(); } } Bar::boo(); ?> -Andrei http://www.gravitonic.com/ "The day Microsoft makes something that doesn't suck, is p

Re: [PHP-DEV] iterating objects with interfaces

At 02:48 12/03/2003, Stephen Thorne wrote: How soon till (''.($_GET['textArea']->strip_tags()).'')->print(); ? Considering $_GET is an array of strings, infinity :) Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scope and namespace

At 23:48 12/03/2003, Andrei Zmievski wrote: Seeing as how we now have only one-level deep namespaces and classes (which is another topic), does it make sense to have both 'scope' and 'ns' fields in zend_op_array structure? I would think they can be merged into one. Not really, we can't. You can ha

Re: [PHP-DEV] Scope and namespace

At 15:54 13/03/2003, Andrei Zmievski wrote: On Thu, 13 Mar 2003, Zeev Suraski wrote: > Not really, we can't. You can have functions inside a namespace, that > don't have a class entry attached to them. > I guess we could create some hybrid of the namespace and ce, but it would

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

I believe he meant the query id's that the engine uses, and not the auto increment id's. Wez's response was accurate, we'll overflow at some point. This is basically because PHP was designed with short requests in mind. We could probably fix it relatively easily for ZE2. Zeev At 13:15 25/03

Re: [PHP-DEV] HUGE memory consumption on fread()

Any chance you're using output buffering? Zeev At 12:25 14/08/2002, Joost Lek wrote: >Hello everyone, > >I am new to this list, but urgently in need of a solution for a problem i >am currently facing. >First, i'll give a description of my current platform: >Linux 2.4.18 (origninally slackware,

Re: [PHP-DEV] ZE2 and PHP

At 14:21 16/08/2002, Dan Hardiker wrote: >Hi, > >As php user's requests are getting closer and closer to what ZE2 is >offering (eg: back tracing, private/protected classes, extra inheritance >functionality, etc) ... > >1. When is ZE2 expected to be released (if its not already) My guess is early

Re: [PHP-DEV] ZE2 and PHP

At 17:43 16/08/2002, Brad LaFountain wrote: >--- Zeev Suraski <[EMAIL PROTECTED]> wrote: > > At 14:21 16/08/2002, Dan Hardiker wrote: > > >Hi, > > > > > >As php user's requests are getting closer and closer to what ZE2 is > > >offe

Re: [PHP-DEV] ZE2 and PHP

At 18:26 16/08/2002, Dan Hardiker wrote: > >>2. When is it expected to be available in a development (experimental) > >> or production release? > > > > It already is - go to www.php.net, and search for 'alpha'. > > > http://www.php.net/do_download.php?download_file=php-4.3.0-dev-zend2-alpha2.tar.

[PHP-DEV] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

Just wondering - why are we even using atime? I think lots of filesystems don't support it, but regardless of that - as far as I recall from reading the session code, if a session is opened for reading - it is also going to be rewritten at the end of the session. So, it should be quite safe t

[PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

ed. This function would be useful actually. > >-Rasmus > >On Sat, 17 Aug 2002, Zeev Suraski wrote: > > > Just wondering - why are we even using atime? I think lots of filesystems > > don't support it, but regardless of that - as far as I recall from reading > > th

[PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

t seem like >a good idea. I suppose we could change the default to mtime, implement >session_readonly() and give people the option to switch it to atime. > >-Rasmus > >On Sat, 17 Aug 2002, Zeev Suraski wrote: > > > Just wondering - why are we even using atime? I think lots o

[PHP-DEV] 4.2.3

I'd like to raise the option of releasing 4.2.3 again. I believe that it would be quite a while before 4.3.0 is out, and there are quite a few fixes in the 4.2 branch that should make the userbase as soon as possible, especially the Windows userbase. I think that releasing 4.2.3 can be done wi

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

about the same time as accessing it on an atime-enabled filesystem, I think. This would give us the best of both worlds. Zeev At 13:39 17/08/2002, Zeev Suraski wrote: >Ok, that makes sense. I like the idea of being able to configure whether >you want to use mtime or atime, so that non a

Re: [PHP-DEV] 4.2.3

er though) have been looking at the dbm_* >functionality on Windows. We're questioning if it ever worked at all. > >I can run through a list if there is a desire to see one. > >On Sat, 17 Aug 2002, Zeev Suraski wrote: > > > I'd like to raise the option of releasing 4.

Re: [PHP-DEV] 4.2.3

back ported. None of it is new >functionality, all of it is fixes to bugs. > >And I still think the Tru64/AIX issues will need to be solved as well. > >On Sat, 17 Aug 2002, Zeev Suraski wrote: > > > I'd really like to avoid waiting this time, though (the enemy of good is >

RE: [PHP-DEV] 4.2.3

At 16:41 17/08/2002, Sebastian Nohn wrote: >Why release a RC for a software that has some known bugs not fixed. PHP x.y.z has known bugs that are not fixed, for any given x, y and z, since forever, and until the of time. Realize that, and decisions become much simpler. Releasing a new version

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

At 16:54 17/08/2002, James E. Flemer wrote: >Would it be difficult to just add a "dirty" flag somewhere, Not really, because today people can modify the session data by simply changing $_SESSION. We have no way of detecting whether $_SESSION was changed, as it's just a regular variable (for th

Re: [PHP-DEV] 4.2.3

h Jaguar/10.2 being released in a >few days. There have been numerous fixes to all the code bases in an >effort to get support for OSX implemented into them (ext/java still being >a bastard). > > >On Sat, 17 Aug 2002, Zeev Suraski wrote: > > > I think it makes good se

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] 4.2.3

At 17:52 17/08/2002, Sebastian Nohn wrote: >No! This simply confuses users! Someone reported a bug n weeks ago, this bug >"has been fixed in CVS" n-x weeks ago. Now there is a new release an WOW! >this bug is'nt fixed! Fixed in CVS means fixed in CVS and the user expects >this bug to be fixed in t

Re: [PHP-DEV] 4.2.3

. The fixes are piling up in CVS. Stig, could you give >us a status report? Do you still have time to push this release? > >-R > >On Sat, 17 Aug 2002, Zeev Suraski wrote: > > > Ok then, I retract my suggestion to release 4.2.3. > > > > Zeev > > > >

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 22:28 17/08/2002, Xavier Spriet wrote: >This is quiteconcerning. >It appears the PHP release process is not suited to the way PHP is >developed anymore >and this can lead in severe inconsistencies. >What seemed to have happened is that several bugfixes were fixed in CVS >instead of the bugfix

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 22:58 17/08/2002, Sascha Schumann wrote: > > 64-bit fixes (for whatever reason), I think that's quite alright. 64-bit > > support is a major thing, which people, especially businesses, will not > > really expect to be implemented in a bug-fix release. > > 64-bit support has worked for year

[PHP-DEV] Re: [Patch] PHP segv fix bug #17000

Nope, that's not a valid patch. zval_dtor() is not supposed to pay any attention to refcount's. It should be fixed at a different level, I'll check into it. Zeev At 22:58 17/08/2002, Ilia A. wrote: >Since there is no check if there is a refcount before freeing an object there >is a segv if t

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 00:18 18/08/2002, Sascha Schumann wrote: > I've had at a look at the bug reports Sebastian Nohn pointed > out. None of these are major issues. Annoying, but nothing > which would qualify PHP as being "buggy as hell". Still, > having these fixes in 4.2.3 would be a definitive

Re: [PHP-DEV] 4.2.3

I did not intend to reply to that, but generally, the reasons I think 4.2.3 should either be released in the immediate future or not released at all are (a) clashing with the 4.3.0 release process (b) momentum. The most serious problem PHP releases have suffered from, in my opinion, ever sense

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

I said before - I prefer not having any changes in ZE1, for both stability reasons and also as a motivation to get ZE2 out the door more quickly. Zeev At 17:21 18/08/2002, Thies C. Arntzen wrote: > if noone objects i'm going to commit this to -HEAD (and we > can start discussing it the

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime

I don't think that's the way to do it at all. In theory, it's no problem to track whether changes were made to the session data, and perform the write at the end of the request, only if we tracked a change. That's only in theory, though, since with the fancy new $_SESSION array, there's no wa

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

ion to move to > > ZE2. If not it'll be hard to push it out and we all know that it's a very > > important step for PHP. As it is, there is still not enough momentum > behind > > it. > > Andi > > > > At 05:38 PM 8/18/2002 +0300, Zeev Suraski wrote: >

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 20:29 18/08/2002, Rasmus Lerdorf wrote: >I don't think we should stop people from tweaking ZE1. ZE2 is probably >more than a year away from realistically being available to a lot of >people. No, it's not. It's around 6 months away from being production-quality. That's exactly the mispercept

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 20:40 18/08/2002, [EMAIL PROTECTED] wrote: >I'm not happy with that indeed. ZE1 is still the current version, and I >wouldn't see any reason to not extend it (or even backport things from >ZE2 as this patch is largely about). Why not backport all the changes then? I'm -1 on introducing any new

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 20:24 18/08/2002, Thies C. Arntzen wrote: >On Sun, Aug 18, 2002 at 08:19:52PM +0300, Zeev Suraski wrote: > > I haven't, because of the two reasons I mentioned. There's nothing about > > the specifics of the patch that can make me change my personal mind about >

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 20:54 18/08/2002, Thies C. Arntzen wrote: > BTW: the code we're talking about is neither magic nor very > complex. andi, sorry i you felt me stepping on your feet;-) And yet you took it from ZE2 a couple of months after it was written, as opposed to two years ago when ZE1 was already

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 21:00 18/08/2002, Thies C. Arntzen wrote: > this is more than a little frustrating for me and i'm sure > not too many ppls will be happy about your "desupport notice" > for ZE1. It has nothing to do with desupport. I fixed ZE1 issues, *COMPLEX* ones, that cost me days of low leve

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 20:56 18/08/2002, Rasmus Lerdorf wrote: > > At 20:29 18/08/2002, Rasmus Lerdorf wrote: > > >I don't think we should stop people from tweaking ZE1. ZE2 is probably > > >more than a year away from realistically being available to a lot of > > >people. > > > > No, it's not. It's around 6 months a

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 21:00 18/08/2002, Thies C. Arntzen wrote: > so - cool, you (z&a) stopped working on it. does that mean > it's now written in stone and nobody is allowed to touch it? Feature-wise, I hope so. There's so much I can do to actually make it so, though. > We have a pretty clear roadmap f

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 21:15 18/08/2002, Thies C. Arntzen wrote: >On Sun, Aug 18, 2002 at 09:00:25PM +0300, Zeev Suraski wrote: > > At 20:54 18/08/2002, Thies C. Arntzen wrote: > > >BTW: the code we're talking about is neither magic nor very > > >complex. andi, sorry i y

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 22:20 18/08/2002, Xavier Spriet wrote: >As long as there is momentum on the development process and on the QA >process when needed, >I don't think release momentum matters that much. Right. Since the first part of the sentence does not stand in reality, the direct result is that momentum ma

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 21:58 18/08/2002, Wez Furlong wrote: >Generally speaking, and please don't take offense, I think that one >of the problems with ZE2 is that development is slow. I understand >that there are several very good reasons for that, but the real >problem is that there aren't enough people with enough

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

ge- > From: Edin Kadribasic [mailto:[EMAIL PROTECTED]] > Sent: Sun 18/08/2002 4:21 PM > To: Xavier Spriet; Zeev Suraski > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [PHP-QA] Re: [PHP-DEV] 4.2.3 > > > >

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 10:12 19/08/2002, [EMAIL PROTECTED] wrote: >I'd like to hear Stig's opinion on 4.3.0 first, and I tend to agree that >we need a 4.2.3 too. I can even find time to do the release process and >manage QA, providing there is any feedback to the RC. I would actually like to do that once, if you don

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 10:15 19/08/2002, [EMAIL PROTECTED] wrote: > > I would actually like to do that once, if you don't mind :) > >I don't mind at all... but what is the reason for this? :) Well, first it's been a while since I did, but I'd also like to see it working in the 'new way' once, with the automated QA.

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 10:22 19/08/2002, [EMAIL PROTECTED] wrote: >On Mon, 19 Aug 2002, Zeev Suraski wrote: > > > At 10:15 19/08/2002, [EMAIL PROTECTED] wrote: > > > > I would actually like to do that once, if you don't mind :) > > > > > >I don't mind at all... but

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 11:36 19/08/2002, Thies C. Arntzen wrote: > my apache 2.0 thing got misinterpreted a bit - let me > clearify: apache2.0 is ready, it works and it's even better > than 1.3 (the httpd itself). but ppls don't upgrade all > threir servers immediatly. as rasmus mentioned, the same >

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 13:30 19/08/2002, Thies C. Arntzen wrote: >On Mon, Aug 19, 2002 at 11:45:30AM +0300, Zeev Suraski wrote: > > > > How often do you call a function that gives you your current backtrace in > > C? In my many years of C experience, I would have to say that the > accurate

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 07:55 20/08/2002, Brad LaFountain wrote: > You as a Zend owner who's business could be very propitable for Zend2 > success >or you as a php developer Brad, This is CLEARLY as PHP developers. We happen to have quite a bit of experience in getting the userbase to convert from one version to

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 17:21 20/08/2002, Brad LaFountain wrote: > Ok this experience you are talking about is converting php3 => php4 correct? Both PHP/FI 2 => PHP 3 and PHP 3 => PHP 4 >Well how many people are were using php3 at that time? Siginifntly less? The >conversion from php3 to php4 offered a more stable

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 18:45 20/08/2002, Brad LaFountain wrote: >First of all I wanna just say that I'm just stating my opnion. You seem to be >getting angry. Im not trying to say your wrong and I'm right. Please don't >take >it like that. I'm not angry at all :) > Obvisouly we all have our own opnion I wanted t

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 19:35 20/08/2002, Rasmus Lerdorf wrote: >We should not be talking about carrots here, and Thies is not saying >"screw you" to you. He wants to help PHP users today. That almost sounds like a Microsoft tagline :) Come on, you know what he meant. If Andi didn't implement this efficient approa

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 20:04 20/08/2002, Rasmus Lerdorf wrote: >If you could explain to me why holding back a useful feature that could >help a lot of users today is somehow better for these users, then you >might be able to convince me. Is it because by holding it back now we can >force a portion of users who are d

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 20:27 20/08/2002, Brad LaFountain wrote: > I don't see it as a slap in the face it should be considered a > compliment that >it was written well enough to be backported. Uhm, well, it isn't. I think it was obvious that it was a pretty neat implementation, there was really no need for any a

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

At 16:02 20/08/2002, Jani Taskinen wrote: >On Tue, 20 Aug 2002, Andi Gutmans wrote: > > >I still think it shouldn't go in. This is the only feature in Engine 2 > >which might make non-OOP people convert. Once this isn't in Engine 2 we > >don't have a carrot for them. > > I guess you want PHP 5

Re: [PHP-DEV] Interfaces in PHP

At 09:30 21/08/2002, Ben Dischinger wrote: >You don't quite get the same functionality from extending a class as you >would from implementing an interface. If I'm extending temperature what >keeps me as a user from not overriding any of those functions? Or what if I >want to extend a different cl

RE: [PHP-DEV] PHP 4.3 and PHP 5

At 17:55 21/08/2002, Joseph Tate wrote: >o Rewrite the ISAPI IIS interface. "Gasp". From the ground up, or find >some other way to fix bug #15333. The work arounds listed in the bug report >are not acceptable in production systems, just as temporary stop-gap methods >for developing new applicat

Re: [PHP-DEV] PHP 4.3 and PHP 5

At 23:09 21/08/2002, Shane Caraveo wrote: >Rasmus Lerdorf wrote: >>But how do you propose we come up with perfect Apache 2.0 support? > >FastCGI :) Sounds like a plan (seriously) Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: SV: [PHP-DEV] PHP 4.3 and PHP 5

At 11:20 22/08/2002, Carsten Gehling wrote: >Correct me if I'm wrong, but once these issues about thread-safety have been >solved, it will not only affect the behavioud towards Apache 2.x but also >the ISAPI module, would it not? They're only partially related. Most of the libraries under Window

[PHP-DEV] 4.2.3

As per Dan K, most of the important bug fixes were backported to the 4.2 branch (thanks everyone!) I'll pack 4.2.3RC1 tomorrow morning, so if anybody has any last minute bug fixes to put in, now's the time! Zeev -- PHP Development Mailing List To unsubscribe, visit: ht

[PHP-DEV] Re: Object Overloading

At 16:44 22/08/2002, Sam Liddicott wrote: >Zeev I just wanted to make you aware that not just the Java module, but also >all SWIG generated php modules also use the object overloading propget and >propset way of accessing properties of the wrapped objects. > >I hear this was being revamped for zen

Re: [PHP-DEV] Another output buffering oddity

Sebastian's right, even though this does require that the code allows this. Was this changed since 4.2? At 13:24 25/08/2002, Sebastian Bergmann wrote: >Marcus Börger wrote: > > You are using an undocumented feature of ouput. > > > > if (!$this->_started) { > > ob_start( >

Re: [PHP-DEV] ob_start() and objects

At 16:25 25/08/2002, Marcus Boerger wrote: >To have ob_start() working again i first allowed >array(object,method). > >In addition to that i allowed single objects to be passed >which results in calling __output_handler() method of >that object. Why? Output handling doesn't appear to be somethin

Re: [PHP-DEV] ISAPI Crash Debugging Notes

First off, can you try using http://www.php.net/~zeev/php-4.2.3RC1.tar.gz and see if you experience the same problems? I've made some thread-safety related fixes there, even though none should lead to a hard crash... If it doesn't solve the problem, can you send me as much information about t

Re: [PHP-DEV] ISAPI Crash Debugging Notes

At 09:53 27/08/2002, Michael Sisolak wrote: > > >i've been doing some debugging of the crashes when running php under > > >the isapi sapi. is anybody else currently looking at this? if you > > >are let's talk - here are my notes so far. > > > > first off, can you try using > > http://www.php.net

Re: [PHP-DEV] Segfault in ob_*() callback

At 16:10 01/09/2002, Marcus Börger wrote: >The problem is that in function >PHPAPI void php_end_ob_buffer(zend_bool send_buffer, zend_bool just_flush >TSRMLS_DC) > >the user function is called wether or not send_buffer is zero. (Zero means >flush >here and means the function must not be called,

Re: [PHP-DEV] Segfault in ob_*() callback

At 17:51 01/09/2002, Marcus Börger wrote: >At 15:25 01.09.2002, Zeev Suraski wrote: >>At 16:10 01/09/2002, Marcus Börger wrote: >>>The problem is that in function >>>PHPAPI void php_end_ob_buffer(zend_bool send_buffer, zend_bool >>>just_flush TSRMLS_DC) >&

Re: [PHP-DEV] segfault on adding empty heredoc to string

Mark them as critical and they'll get some attention :) Is this bug new to the latest CVS or does it occur with 4.2? At 01:10 02/09/2002, Jani Taskinen wrote: > > Crashes with latest CVS HEAD here too: > >0x828b505 in _zval_dtor (zvalue=0xbfffd540, __zend_filename=0x8376000 >"/usr/src/web/ph

Re: [PHP-DEV] mbstring

At 05:15 02/09/2002, Yasuo Ohgaki wrote: >Marcus Börger wrote: >>At 01:24 02.09.2002, you wrote: >> >>>Brian France wrote: >>> I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if

Re: [PHP-DEV] mbstring

At 03:41 02/09/2002, Brian France wrote: >I know this is ugly, but what about making the extensions handle it >themselves? It's actually not ugly at all. Letting the modules handle it themselves is the Right Way, because only they know what they need. The only question is whether we need to

RE: [PHP-DEV] mbstring

I do agree with Wez (not 'completely agree', though ;) FWIW, mbstring was/is indeed enabled by default under Windows, and I think that at this stage this is not a good idea. There was at least one serious crash in the code that was introduced by the changes, into both the mbstring version and

RE: [PHP-DEV] mbstring

At 13:19 02/09/2002, James Cox wrote: >As I see it, PHP was designed with speed and simplicity in mind. It was indeed.. >Having the burden of a large number of extra modules compiled in by >default doesn't help, and deviates from this path. Not really. Speed-wise, adding modules has a negligi

  1   2   3   4   5   6   7   8   9   10   >