Am 03.01.2011 02:41, schrieb Enrico Weigelt:
> >
> > No, as usual on Gentoo, config files are never overwritten, but
> > written to another place and tools like etc-update show you the
> > differences. I've merged the configs manually, and I'm pretty
> > sure I didn't add anything like error_repor
Am 03.01.2011 02:41, schrieb Enrico Weigelt:
> * Rasmus Lerdorf wrote:
>
>> Also, you said this happened between 5.3.2 and 5.3.3? Looking through
>> the diff between those two versions we did not add any new deprecation
>> warnings. We tend to not do that in a minor release. At least I don't
>>
On 3/01/11 2:24 PM, David Muir wrote:
On 12/12/10 01:47, Stefan Marr wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trai
On 12/12/10 01:47, Stefan Marr wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trait is to use
either abstract set/get m
Am 03.01.2011 02:19, schrieb Enrico Weigelt:
> In essence you say here, that I should diff the production config
> example from one version to another to find out what changed
> and adapt my config, on each update.
Hm thats your job as sysadmin
> Adds about 15mins extra work
What is your job
>
Hi!
In essence you say here, that I should diff the production config
example from one version to another to find out what changed
No. You should use it now and should always have used it. There was no
change in this config parameter at least since 5.3.0. Look in the public
SVN repo if you d
Hi!
Something seem to turn them on magically, no idea what it was.
(perhaps the config variable name changed ? ;-o)
No, it has not. Whatever "magically changed" on your system was not
caused by PHP. On the other hand it gave you a chance to fix a serious
configuration problem on your server,
On 1/2/11 5:45 PM, Enrico Weigelt wrote:
> * Rasmus Lerdorf wrote:
>
>> Nope, we really didn't change anything. The simple explanation is
>> that you installed without or with a different php.ini from the
>> previous version.
>
> Of course, I've kept my original (old) config and just adapted
>
* Rasmus Lerdorf wrote:
> Nope, we really didn't change anything. The simple explanation is
> that you installed without or with a different php.ini from the
> previous version.
Of course, I've kept my original (old) config and just adapted
some things to the new default config manually. So it
* Rasmus Lerdorf wrote:
> Also, you said this happened between 5.3.2 and 5.3.3? Looking through
> the diff between those two versions we did not add any new deprecation
> warnings. We tend to not do that in a minor release. At least I don't
> recall the last time we did so.
That's where I not
On Mon, 03 Jan 2011 01:14:42 -, Enrico Weigelt
wrote:
* Stas Malyshev wrote:
Of course, nobody personally has any time. But PHP is a volunteer
project, so if nobody has the time, nobody should complain about "php
developers not caring". PHP developers are caring, but it's not humanly
p
On 1/2/11 5:14 PM, Enrico Weigelt wrote:
> * Stas Malyshev wrote:
>> Hi!
>>
>>> IIRC many deprecation warnings, which totally broke the output.
>>
>> Err, you actually output the warnings in your output? In production?!
>
> Something seem to turn them on magically, no idea what it was.
> (perhap
* Stas Malyshev wrote:
> Hi!
>
> >Unfortunately, yes. I didn't enable that - happend magically
> >on the update. That's yet another strange point here - why do
> >such warnings go stdout per default, instead of syslog ? ;-o
>
> You should use settings based on php.ini-production in production. O
* Stas Malyshev wrote:
> Hi!
>
> >IIRC many deprecation warnings, which totally broke the output.
>
> Err, you actually output the warnings in your output? In production?!
Something seem to turn them on magically, no idea what it was.
(perhaps the config variable name changed ? ;-o)
> >I, per
On 1/2/11 4:52 PM, Enrico Weigelt wrote:
> * Rasmus Lerdorf wrote:
>
>> Your application broke because of a deprecation warning? Are you
>> sending PHP errors to the user in your production code?
>
> Unfortunately, yes. I didn't enable that - happend magically
> on the update. That's yet anot
* James Butler wrote:
> As a 'grown up' you should never expect changes to a system
> to just work without testing, any change introduces risk,
> you need to mitigate against that risk by testing.
True, but applications should be designed in a way that minimizes
the risk of breaks.
> Irrespect
Hi!
Unfortunately, yes. I didn't enable that - happend magically
on the update. That's yet another strange point here - why do
such warnings go stdout per default, instead of syslog ? ;-o
You should use settings based on php.ini-production in production. One
of these is display_errors=Off. Us
* Rasmus Lerdorf wrote:
> Your application broke because of a deprecation warning? Are you
> sending PHP errors to the user in your production code?
Unfortunately, yes. I didn't enable that - happend magically
on the update. That's yet another strange point here - why do
such warnings go stdo
>> Nonetheless, it's a significant undertaking to deal with the complexity of
>> the language. There are dozens of tiny little edge cases in PHP's parsing
>> that require bunches of extra parser rules. An example from above is the
>> difference between using "statement" and "inner-statement" for
Hi Guilherme
You wrote that Java spec? Cool! Also very nice example of the PHP
EBNF! I think PHP needs a canonical one of those and that the parser
should be rewritten to represent said EBNF. Thats what I'm dreaming of
at least :)
Cheers
Rune
On Sat, Jan 1, 2011 at 5:23 PM, guilhermebla...@gmail
Hello, PHP developers,
I'm new to the list, but have been using PHP for a number of years, have
done a little hacking in the source code, and have an interest in the
development of the language.
Particularly recently I have been reading with a good deal of excitement
Stefan Marr's RFC on 'horizo
21 matches
Mail list logo
