Marcus Boerger schrieb:
> ...obviously we cannot change the past.
This is a problem to be fixed. Changing the past is to important. Please
implement it.
AllOLLi
Real stupidity beats artificial intelligence every time
[Ridcully in Terry Pratchett's Hogfather]
--
PHP Internals - PHP
On Mon, 2005-09-19 at 22:36 +0400, Antony Dovgal wrote:
> 1) They are only notices, you don't *have* to fix them as they can be safely
> silenced.
It would be nice if they could be safely silenced, but the bug I
just filed about the BC break in 4.4 (#34551) was just marked bogus,
so it looks lik
Hello Antony,
Monday, September 19, 2005, 8:36:23 PM, you wrote:
> On 19.09.2005 20:50, Andrey Nikolaev wrote:
>>> Maybe you don't know how much time *I* lost with both finding what
>>> the problem here was (abour 5 weeks) and fixing all *our* bad code (about 7
>>> weeks). I
>>> Derick
>> Deric
On 19.09.2005 20:50, Andrey Nikolaev wrote:
Maybe you don't know how much time *I* lost with both finding what
the problem here was (abour 5 weeks) and fixing all *our* bad code (about 7 weeks). I
Derick
Derick, it's great job, thanks, that you spend so much time for fixing this
bug. But...
No
> Maybe you don't know how much time *I* lost with both finding what
> the problem here was (abour 5 weeks) and fixing all *our* bad code (about 7
> weeks). I
> Derick
Derick, it's great job, thanks, that you spend so much time for fixing this
bug. But...
Now should we count how many days it's n
Pierre Joye wrote:
All the points I tried to explain in the last 2 months or so were
about that and only that. Every oppinions have been raised.
Short versions: Stop pollitic :)
Pierre I think *ONE* problem here was that those of us who have moved on
from PHP4 were probably not taking any
Hi
I was lost in this thread. Could someone post resume from this
discussion? How can I deal with this in 4.3, 4.4, 5+?
Thanks
--
Ondrej Ivanič
([EMAIL PROTECTED])
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
At 22:08 15/09/2005, Douglas wrote:
> It does indeed relate. You now have the problem that you have to explain to
> people why they cannot do "return new FooBar();" in their methods.
Doesn't that only apply to code you write that must be compatible with PHP4?
In which case, is it still somethin
> It does indeed relate. You now have the problem that you have to explain to
> people why they cannot do "return new FooBar();" in their methods.
Doesn't that only apply to code you write that must be compatible with PHP4?
In which case, is it still something you would have to explain to someon
> How does the first part relate to the second part in any way? The
> confusion level? If that's your point, then we're doing our best to
> decrease confusion rather than foster it. PHP 5 was a big step in the way
> with its new object model and the much reduced need for references. As a
> matt
At 14:57 15/09/2005, David Zülke wrote:
I think he has a point. Regardless, I'd like to add something else:
Right now, BC has been broken and non-transparent, illogical behaviour been
introduced due to engine internals. It will never be obvious nor logical to
new users why they cannot return a n
On Thu, 15 Sep 2005, Leigh Makewell wrote:
> part of it. A major part is how the developers interact with the users. If you
> have people like Derick insulting your users and telling them to STFU then you
> have to have serious words with him, and if necessary get rid of his arse,
> because he rep
On 9/15/05, Leigh Makewell <[EMAIL PROTECTED]> wrote:
> I believe all of this could of been avoided with careful PR. Now you
> need some major PR to repair the damage.
All the points I tried to explain in the last 2 months or so were
about that and only that. Every oppinions have been raised.
If
tember 15, 2005 1:37 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Reference handling change and PHP 4.4.0
>
> Zeev Suraski wrote:
> > Let me let you in on a secret as well. This tone isn't going to get you
> > anywhere.
> >
>
> No it won'
On 9/15/05, Leigh Makewell <[EMAIL PROTECTED]> wrote:
> [...] There are too many viable
> options out there to warrant sticking with the relatively fragile and
> limited PHP platform. "Change to Ruby. It's heaps better!"
FWIW, Ruby is changing as well.
Regards,
Michael
--
PHP Internals - PHP Run
Rasmus Lerdorf wrote:
That's fine, and you shouldn't care, I agree. I argued much the same
point just yesterday in a chat with Ilia. You do however seem to be
glossing over the fact that this new check can be very helpful. Take
this case:
sort(array(3,2,1));
Or any other example where the
Zeev Suraski wrote:
Let me let you in on a secret as well. This tone isn't going to get you
anywhere.
No it won't. But the diplomatic one didn't get us anything except
insults and put downs. This approach has at least got some serious
attention. :)
For the record, I was against fixing th
> Yes it is legal because it worked
That's nonsense. Even in the C-language certain things have worked in the
past because of compiler bugs. Newer GCC versions have fixed it and broken
C-code. Too bad for the users, but it improved the compiler's C-compliance.
Something might work, but that doesn'
Leigh Makewell wrote:
> Rasmus Lerdorf wrote:
>
>> Well, that is the point, it didn't actually work. Code similar to this
>> caused memory corruption. So while you may not have seen an instant
>> crash, over time and in certain conditions you would get unexplained
>> crashes. In order to fix th
At 10:23 15/09/2005, Leigh Makewell wrote:
Rasmus Lerdorf wrote:
Well, that is the point, it didn't actually work. Code similar to this
caused memory corruption. So while you may not have seen an instant
crash, over time and in certain conditions you would get unexplained
crashes. In order to
Rasmus Lerdorf wrote:
Well, that is the point, it didn't actually work. Code similar to this
caused memory corruption. So while you may not have seen an instant
crash, over time and in certain conditions you would get unexplained
crashes. In order to fix this bug we needed to check for this so
Leigh Makewell wrote:
> Rasmus Lerdorf wrote:
>
>> This is where it gets tricky. Is this legal code?
>
> Yes it is legal because it worked.
Well, that is the point, it didn't actually work. Code similar to this
caused memory corruption. So while you may not have seen an instant
crash, over t
Rasmus Lerdorf wrote:
So while the tone of some of these messages may not be great,
> often the suggestion that the code in question isn't very good is
accurate.
Rasmus, I think where some of the concern and confusion lies is with
those of us who have been doing, or at least attempting, some
Rasmus Lerdorf wrote:
This is where it gets tricky. Is this legal code?
Yes it is legal because it worked. Whether it is strictly "correct" or
not is another argument. People write bad code all the time, but it
doesn't make it any less legal. In minor version changes BC is not a
secondary p
Leigh Makewell wrote:
> a perfectly legal statement like this $x = current(explode(' ','a b'));
In this particular case, current() did not need to take a reference
since it doesn't modify anything. This has been fixed in CVS. That's
still not how I'd write that though. I would write:
list($x
Derick Rethans wrote:
On Wed, 14 Sep 2005, Leigh Makewell wrote:
Derick Rethans wrote:
I doubt any application would really stopped working - except for a friendly
notice when people wrote bad code.
Except if you had read Colin's messages you would see that his code *had*
stopped working.
Derick Rethans wrote:
But it just could as well have been because he was relying on the memory
corruptions. Hard to tell without code.
Derick
As I mentioned in my reply to Rasmus above, the problem seems to be
stemming from a class that acts like a map of objects. Most of my PHP4
code woul
Derick Rethans wrote:
We found this out the hard way yesterday when our server administrator
upgraded our production server to PHP 4.4.0 (even though the Debian package
description said it was a PHP 4.3.x release). We ended up with hundreds of
errors and many, many vhosts stopped working correct
On 9/14/05, Derick Rethans <[EMAIL PROTECTED]> wrote:
> I doubt any application would really stopped working - except for a
> friendly notice when people wrote bad code.
Derick, I do not know if you ever learn but... Stop saying that people
wrote bad codes and this is why they code could break. T
On Wed, 14 Sep 2005, Leigh Makewell wrote:
> Derick Rethans wrote:
> > I doubt any application would really stopped working - except for a friendly
> > notice when people wrote bad code.
>
> Except if you had read Colin's messages you would see that his code *had*
> stopped working.
But it just
Derick Rethans wrote:
I doubt any application would really stopped working - except for a
friendly notice when people wrote bad code.
Derick
Except if you had read Colin's messages you would see that his code
*had* stopped working.
Leigh :)
--
PHP Internals - PHP Runtime Development Mail
On Wed, 14 Sep 2005, Leigh Makewell wrote:
> However, breaking BC between 4.3 and 4.4 when 4.3 is a dead branch causes can
> cause some problems for system admins. What happens if the software being used
> is never updated to 4.4? There are important security updates that need to be
> applied, but
On Wed, 14 Sep 2005, Colin Tucker wrote:
> Hello all,
>
> I know this issue has most likely been discussed to death here so I apologise
> in advance for starting a new thread about it. I just need to get my head
> around the reasoning for introducing this change to PHP4 (4.4 branch). I can
> un
Rasmus Lerdorf wrote:
Once again, it is an E_NOTICE in 4.4. And yes, not displaying it makes
it go away. Staying with 4.3 because of this is nuts. If you are
seeing this notice under 4.4 that means you are most likely getting
random memory corruption under 4.3. Move to 4.4 to fix the memory
c
Leigh Makewell wrote:
> Pierre Joye wrote:
>
>> No, 4.3.x is a dead branche. But the problem is much more easier to
>> fix in 4.4.0. Do what you always do in production servers, do not
>> display errors/notices, especially as 4.4.0 raises only notices for
>> the reference problem.
>>
>> Regards,
>
Pierre Joye wrote:
No, 4.3.x is a dead branche. But the problem is much more easier to
fix in 4.4.0. Do what you always do in production servers, do not
display errors/notices, especially as 4.4.0 raises only notices for
the reference problem.
Regards,
--Pierre
Well that is exactly why this i
Hi Rasmus, thanks for replying, I appreciate your feedback.
Rasmus Lerdorf wrote:
We have been looking to see if there is a way to fix the memory
corruption issue in a way that has less of an impact on existing code.
This doesn't change the fact that every error you get is actually an
error in t
On 9/14/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> but at the same time the breakage of existing apps has been
> more widespread than I think anybody anticipated.
Than "anybody" liked to anticipate could better said.
> I'd still want to throw a notice to let people know they are doing someth
Colin Tucker wrote:
> I know this issue has most likely been discussed to death here so I
> apologise in advance for starting a new thread about it. I just need to
> get my head around the reasoning for introducing this change to PHP4
> (4.4 branch). I can understand making the change to PHP5, bu
On 9/14/05, Colin Tucker <[EMAIL PROTECTED]> wrote:
> Hi Jani,
>
> Yes, the increase in the middle digit. ;)
>
> Ok, so does this mean that the 4.3.x and 4.4.x branches will now be
> updated separately? Say, if a serious vulnerability was detected in
> 4.3.x an 4.4.x, and separate release would
Hi Jani,
Yes, the increase in the middle digit. ;)
Ok, so does this mean that the 4.3.x and 4.4.x branches will now be
updated separately? Say, if a serious vulnerability was detected in
4.3.x an 4.4.x, and separate release would be issued for both?
Kind regards,
Colin.
Jani Taskinen wro
You do understand the difference between 4.3.x and 4.4.x? :)
(yes, this issue has been beaten to death already)
--Jani
On Wed, 14 Sep 2005, Colin Tucker wrote:
Hello all,
I know this issue has most likely been discussed to death here so I apologise
in advance for starting a ne
42 matches
Mail list logo
