On Thu, 2004-04-01 at 16:46, Derick Rethans wrote:
> On Thu, 1 Apr 2004, Joseph Lee wrote:
>
> > What's with the logo on phpinfo() today?
> >
> > The php logo has been changed to a dog. Is it a 1st April thing?
>
> Yup
I liked Thies better than the dog :)
regards
Robin
--
Robin Ericsson <[EM
On Thu, 1 Apr 2004, David Giffin wrote:
> Is this going to change back? The php5 documentation on the zend site
> shows that both casting and print/echo should work.
*casting* works fine, we just don't do it automagically:
print (string) $obj;
regards,
Derick
--
PHP Internals - PHP Runtime De
Can you add a default __toString() for all objects (which don't extend or
implement a __toString()) then? Because at least then we could use $str =
$anyobj->__toString(). Otherwise I don't think __toString() has any real
functionality, except for print and echo...
Jevon
- Original Message ---
Hello David,
generally the idea is to change this back. But i don't think we will
be able to solve the related problems before PHP 5.1.
marcus
Friday, April 2, 2004, 2:03:38 AM, you wrote:
> Hi Marcus,
> Is this going to change back? The php5 documentation on the zend site
> shows that both c
Hi Marcus,
Is this going to change back? The php5 documentation on the zend site
shows that both casting and print/echo should work.
I guess people could use the output buffering methods to get the print
data for the time being. A not so happy work around :(
Thanks again,
David
On Fri, 2 Apr
Hello David,
that's correct. See the NEWS file, 3rd entry:
18 March 2004, PHP 5 Release Candidate 1
- Fixed numerous bugs with the just-in-time auto-global initialization, that
could cause $_SERVER, $argv/$argc and other variables not to work properly.
(Zeev)
- Fixed data corruption with
Hi There,
I just got a chance tp update to PHP5 RC1 and noticed that some things
have changed for the __toString method. It seems that it it only getting
called when the object is printed or echo. Casting the object to a string
returns the Object #. Here is an example:
The Script:
In the spirit of release early, release often here is the first and hopefully
the final release candidate of PHP 4.3.6. This release addresses
a bugb introduced by 4.3.5, which results in a crash during shutdown for ZTS
builds (Ex. Win32). Another important fix in this release deals with a bug
i
I'm not sure these functions should be fixed. Personally I always recommend
to people to use foreach() or sometimes each() but never these old
functions. If the only problem is that once we reach the end, we can't call
prev() then I think we should just document this. Using array_valid() in
con
Hello Ilia,
Thursday, April 1, 2004, 9:24:25 PM, you wrote:
> This bug is the result of the engine moving the current array position to 0x0
> if there are no more next elements (next/each) or no more preceding elements
> (prev). The results is that if you were to run:
> $a = array(1,2,3);
> whil
This bug is the result of the engine moving the current array position to 0x0
if there are no more next elements (next/each) or no more preceding elements
(prev). The results is that if you were to run:
the out would be NULL rather then 2. The fix that I just reverted from PHP4
addresses this p
At 10:28 AM 4/1/2004 -0800, Rasmus Lerdorf wrote:
On Thu, 1 Apr 2004, Andi Gutmans wrote:
> I'm OK with RC and 4.3.6 but we should get it out quickly which means we
> should RC ASAP. How much time until the DST issues are fixed? I haven't
> seen any other problematic patches except for Ilia's lates
On Thu, 1 Apr 2004, Andi Gutmans wrote:
> I'm OK with RC and 4.3.6 but we should get it out quickly which means we
> should RC ASAP. How much time until the DST issues are fixed? I haven't
> seen any other problematic patches except for Ilia's latest Zend Engine
> patch which I didn't get a chan
On Thu, 1 Apr 2004, Andi Gutmans wrote:
> I'm OK with RC and 4.3.6 but we should get it out quickly which means we
> should RC ASAP. How much time until the DST issues are fixed?
If all goes well in a couple of hours.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
I'm OK with RC and 4.3.6 but we should get it out quickly which means we
should RC ASAP. How much time until the DST issues are fixed? I haven't
seen any other problematic patches except for Ilia's latest Zend Engine
patch which I didn't get a chance to review first.
Andi
At 12:44 PM 4/1/2004 -
On April 1, 2004 12:25 pm, Rasmus Lerdorf wrote:
> I don't think we should push it out without an RC. I just think we should
> instigate the RC process now rather than waiting. Especially considering
> the fact that there were some non-trivial changes. The more other changes
> we add on top of t
On Thu, 01 Apr 2004, Rasmus Lerdorf wrote:
> I don't think we should push it out without an RC. I just think we should
> instigate the RC process now rather than waiting. Especially considering
> the fact that there were some non-trivial changes. The more other changes
> we add on top of thes
On Thu, 1 Apr 2004, Ilia Alshanetsky wrote:
> On April 1, 2004 12:05 pm, you wrote:
> > Yup, given the fact that the DST change date is fast approaching, it would
> > be good to get the mktime/gmmktime fixes out there soon along with the
> > strftime fix. Nothing says we have to wait until we have
On Thu, 1 Apr 2004, Rasmus Lerdorf wrote:
> On Thu, 1 Apr 2004, Ilia Alshanetsky wrote:
>
> > On April 1, 2004 07:51 am, Edin Kadribasic wrote:
> > > +1 except I would call it 4.3.6. We have precedent for this sort bug fix
> > > release. 4.3.1 if I remember correctly.
> >
> > +1
> >
> > > There we
On April 1, 2004 12:05 pm, you wrote:
> Yup, given the fact that the DST change date is fast approaching, it would
> be good to get the mktime/gmmktime fixes out there soon along with the
> strftime fix. Nothing says we have to wait until we have 100+ bug fixes
> in there. We have fixed 20 or so
On Thu, 1 Apr 2004, Ilia Alshanetsky wrote:
> On April 1, 2004 07:51 am, Edin Kadribasic wrote:
> > +1 except I would call it 4.3.6. We have precedent for this sort bug fix
> > release. 4.3.1 if I remember correctly.
>
> +1
>
> > There were many bug reports regarding some data/time functions, ma
Attached is a patch for the xml extension which fixes the segfault with
objects such as in bug 27821 as well as a few other scripts i've seen
floating around.
Is there a reason why zval_add_ref in xml_set_object was commented out? Yes
I already asked thies and was directed here.
It doesnt make sen
On Apr 1, 2004, at 5:58 AM, Lester Caine wrote:
Andrey Hristov wrote:
Hi,
scripts relying on the API of RC1 and before it will be broken
(exception are
scripts that rely on ext/mysqli).
The API is changed (afaik) in :
Reflection API
ext/sqlite
pecl/ffi
pecl/soap
probably other places.
OK so we ar
On Thu, 1 Apr 2004, Joseph Lee wrote:
> What's with the logo on phpinfo() today?
>
> The php logo has been changed to a dog. Is it a 1st April thing?
Yup
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
What's with the logo on phpinfo() today?
The php logo has been changed to a dog. Is it a 1st April thing?
Joe Lee
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On April 1, 2004 07:51 am, Edin Kadribasic wrote:
> +1 except I would call it 4.3.6. We have precedent for this sort bug fix
> release. 4.3.1 if I remember correctly.
+1
> There were many bug reports regarding some data/time functions, maybe we
> should merge that fix in as well? Rasmus/Derick sh
+1 except I would call it 4.3.6. We have precedent for this sort bug fix
release. 4.3.1 if I remember correctly.
There were many bug reports regarding some data/time functions, maybe we
should merge that fix in as well? Rasmus/Derick should know more about this
one,.
Edin
On Thursday 01 Apr
Hi,
A pretty serious bug crept into 4.3.5.
A few weeks ago, a TSRM fix was commited which was supposed to prevent
memory leaks when PHP ends its execution (shutdown dtor was not being
called in tsrm_shutdown()). This fix causes a crash when a shared extension
registers a dtor function. This is
Its something for me/edink to look into.
--Wez.
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Wez Furlong" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Rui
Hirokawa" <[EMAIL PROTECTED]>
Sent: Thursday, April 01, 2004 12:14 PM
Subject: Re: [PHP-DEV] RC2
> Rui, where d
Rui, where does this stand?
At 10:21 AM 4/1/2004 +0100, Wez Furlong wrote:
Rui mentioned that the mbregex part of mbstring wasn't included in RC1,
so that needs to be looked at (should just be some tweaking of the snapshot
build).
--wez.
- Original Message -
From: "Andi Gutmans" <[EMAIL P
Andrey Hristov wrote:
Quoting Lester Caine <[EMAIL PROTECTED]>:
Andi Gutmans wrote:
After all the studlyCaps API fixes
What impact will this have on all existing PHP applications
and extensions?
Hi,
scripts relying on the API of RC1 and before it will be broken (exception are
scripts that rely
Quoting Lester Caine <[EMAIL PROTECTED]>:
> Andi Gutmans wrote:
>
> > After all the studlyCaps API fixes
>
> What impact will this have on all existing PHP applications
> and extensions?
>
> --
> Lester Caine
> -
> L.S.Caine Electronic Services
>
> --
> PHP Inter
Andi Gutmans wrote:
After all the studlyCaps API fixes
What impact will this have on all existing PHP applications
and extensions?
--
Lester Caine
-
L.S.Caine Electronic Services
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
I should also add that this applies to win32 build only.
- Original Message -
From: "Wez Furlong" <[EMAIL PROTECTED]>
To: "Andi Gutmans" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, April 01, 2004 10:21 AM
Subject: Re: [PHP-DEV] RC2
> Rui mentioned that the mbregex part of m
Rui mentioned that the mbregex part of mbstring wasn't included in RC1,
so that needs to be looked at (should just be some tweaking of the snapshot
build).
--wez.
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 01, 2004 9:38 AM
At 12:41 PM 4/1/2004 +0400, Antony Dovgal wrote:
On Thu, 01 Apr 2004 10:36:43 +0200
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Sterling,
>
> It's a stack overflow caused by an infinite loop in function calls (i.e.
> not while/for loop).
So, it's ok and won't be fixed ?
This has been discussed many t
On Thu, 1 Apr 2004, Antony Dovgal wrote:
> On Thu, 01 Apr 2004 10:36:43 +0200
> Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
> > Sterling,
> >
> > It's a stack overflow caused by an infinite loop in function calls (i.e.
> > not while/for loop).
>
> So, it's ok and won't be fixed ?
Exactly (though ad
On Thu, 01 Apr 2004 10:36:43 +0200
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Sterling,
>
> It's a stack overflow caused by an infinite loop in function calls (i.e.
> not while/for loop).
So, it's ok and won't be fixed ?
---
WBR,
Antony Dovgal aka tony2001
[EMAIL PROTECTED] || [EMAIL PROTECTED]
After all the studlyCaps API fixes and some important fixes in the engine
(such as zend.ze1_compatibility_mode), I'd like to release RC2 within the
next couple of weeks (15th of April?).
Are there any serious issues which still need to be addressed?
Andi
--
PHP Internals - PHP Runtime Developme
Sterling,
It's a stack overflow caused by an infinite loop in function calls (i.e.
not while/for loop).
Andi
At 10:17 AM 3/31/2004 -0800, Sterling Hughes wrote:
php5 shouldn't crash _at all_ within an infinite loop because we aren't in
one big execution loop.
-sterling
On Mar 30, 2004, at 11
40 matches
Mail list logo
