Ferenc Kovacs wrote:
>Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
> >Just call error_reporting() at the beginning of your script.
>
>Which ain't possible in drupal (or hardly). You do not write any code.
>You just click together modules, written by others.
Oh, I though
2012.09.04. 23:31, "Lester Caine" ezt írta:
>
> Jan Ehrhardt wrote:
>>
>> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>>>
>>> >Just call error_reporting() at the beginning of your script.
>
>
>> Which ain't possible in drupal (or hardly). You do not write any code.
>> You ju
2012.09.04. 22:25, "Jan Ehrhardt" ezt írta:
>
> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
> >Just call error_reporting() at the beginning of your script.
>
> Which ain't possible in drupal (or hardly). You do not write any code.
> You just click together modules, written b
Jan Ehrhardt wrote:
Lester Caine in php.internals (Tue, 04 Sep 2012 22:30:34 +0100):
Jan Ehrhardt wrote:
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
Just call error_reporting() at the beginning of your script.
Which ain't possible in drupal (or hardly). You do not wri
On Tue, Sep 4, 2012 at 9:17 PM, Adam Jon Richardson wrote:
> On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison wrote:
>> This is probably why the section in the RFC is so small . . . :)
>
> The section covering the potential for potential optimizations isn't so small
> :)
And, apparently, "potentia
On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison wrote:
> This is probably why the section in the RFC is so small . . . :)
The section covering the potential for potential optimizations isn't so small :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
On Tue, Sep 4, 2012 at 4:20 PM, Adam Jon Richardson wrote:
>
> However, as Knuth has said, "It is often a mistake to make a priori
> judgments about what parts of a program really critical, since the
> universal experience of programmers who have been using measurement
> tools has been that their
Lester Caine in php.internals (Tue, 04 Sep 2012 22:30:34 +0100):
>Jan Ehrhardt wrote:
>> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>>> >Just call error_reporting() at the beginning of your script.
>
>> Which ain't possible in drupal (or hardly). You do not write any code.
>
On Tue, Sep 4, 2012 at 6:02 PM, Andrew Faulds wrote:
> APC will make things faster, though, you're missing that. And optimisations,
> which an AST would help, would make it even faster.
Respectfully, I didn't miss that, and I alluded to that potential in
my response (did you read all of my respon
On 04/09/12 23:00, Adam Jon Richardson wrote:
I''m not a core developer, but I do have some concerns about this type
of approach:
As noted in the RFC, most languages do use an Abstract Syntax Tree
(AST), however, as is also noted in the RFC, PHP opcodes are
regenerated by request, which makes P
On Tue, Sep 4, 2012 at 3:57 PM, Nikita Popov wrote:
> Hey folks!
>
> Some people asked me what the advantages of using an AST-based
> parsing/compilation process are, so I put together a few quick notes
> in an RFC:
>
> https://wiki.php.net/rfc/ast_based_parsing_compilation_process
>
> It would be
Jan Ehrhardt wrote:
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>Just call error_reporting() at the beginning of your script.
Which ain't possible in drupal (or hardly). You do not write any code.
You just click together modules, written by others.
Actually Jan - Rasm
On 04/09/12 21:45, Sean Coates wrote:
Pardon my obviously amateur question, but would you build an AST-based
compiler/parser to generate the same (minus the ones you intend to eliminate)
opcodes to run on the VM in the same way as the current compiler does?
Sure. We're changing the route we go
> Some people asked me what the advantages of using an AST-based
> parsing/compilation process are, so I put together a few quick notes
> in an RFC:
>
> https://wiki.php.net/rfc/ast_based_parsing_compilation_process
>
> It would be nice to get a few comments from other core devs on this.
Pardon
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700):
>Just call error_reporting() at the beginning of your script.
Which ain't possible in drupal (or hardly). You do not write any code.
You just click together modules, written by others.
Jan
--
PHP Internals - PHP Runtime Developm
Hi!
> I keep being told that there is nothing wrong with E_STRICT, and again
> someone
> has said that it does NOT cause crashes. I beg to differ here - IT DOES!
If you have a scenario where E_STRICT causes PHP to crash - please
submit a bug to bugs.php.net. If this is your application that is
On 09/04/2012 12:20 PM, Jan Ehrhardt wrote:
> Now that you have changed the subject, I feel free to break in with a
> voice from userland.
>
> Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 09:57:59 -0700):
>> Even with E_STRICT off (...)
>
> Sometimes it is not easy for users to turn off E_ST
Hey folks!
Some people asked me what the advantages of using an AST-based
parsing/compilation process are, so I put together a few quick notes
in an RFC:
https://wiki.php.net/rfc/ast_based_parsing_compilation_process
It would be nice to get a few comments from other core devs on this.
Nikita
-
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine wrote:
> Joomla doesn't use either anyway, and neither do a number of the other sites
> I've been porting, but we still get problems.
Well, just to be sure, have you searched the entire codebase of one of
the existing sites experiencing the issues for
Now that you have changed the subject, I feel free to break in with a
voice from userland.
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 09:57:59 -0700):
>Even with E_STRICT off (...)
Sometimes it is not easy for users to turn off E_STRICT. Lester already
mentioned one scenario: ISP's tend to
Adam Richardson wrote:
If I have any custom error handling I don't know about it. I don't think
>ADOdb or SMARTY adds anything, and I don't load anything.
Well, Smarty can influence error handling:
http://www.smarty.net/docs/en/api.mute.expected.errors.tpl
I think I am right in saying that this
On Tue, Sep 4, 2012 at 2:15 PM, Lester Caine wrote:
> Adam Richardson wrote:
>>
>> I was second-guessing my recall I had a similar issue way back, after
>> Rasmus pointed out that the custom error handler is called even if
>> E_STRICT is off. However, I just looked back at my framework code, I
>>
Adam Richardson wrote:
I was second-guessing my recall I had a similar issue way back, after
Rasmus pointed out that the custom error handler is called even if
E_STRICT is off. However, I just looked back at my framework code, I
see I'm checking to make sure the error level matches, just as Feren
On Tue, Sep 4, 2012 at 1:34 PM, Ferenc Kovacs wrote:
>
> 2012.09.04. 18:58, "Rasmus Lerdorf" ezt írta:
>
>
>>
>> On 09/04/2012 09:36 AM, Adam Richardson wrote:
>> > I think Ferenc is correct in that this sounds like there's a custom
>> > error handler somewhere. If the custom error handler collec
2012.09.04. 18:58, "Rasmus Lerdorf" ezt írta:
>
> On 09/04/2012 09:36 AM, Adam Richardson wrote:
> > I think Ferenc is correct in that this sounds like there's a custom
> > error handler somewhere. If the custom error handler collects error
> > info and then throws an exception (as has been detail
On Tue, Sep 4, 2012 at 12:57 PM, Rasmus Lerdorf wrote:
> Only on a new E_STRICT. Even with E_STRICT off by default, custom error
> handlers are still called, and I think Lester said that turning E_STRICT
> off made it work. So if this is the cause, then it has nothing to do
> with E_STRICT being i
On 09/04/2012 09:36 AM, Adam Richardson wrote:
> I think Ferenc is correct in that this sounds like there's a custom
> error handler somewhere. If the custom error handler collects error
> info and then throws an exception (as has been detailed in various
> blog posts as one manner of unifying the
Ferenc Kovacs wrote:
Using third party code - joomla - only difference between working and not
working is switching E_STRICT on. With display_errors=off one gets a white
screen. I was not surprised as I've had this all the way through with code
from many sources. Yes a lot of the
On Tue, Sep 4, 2012 at 9:43 AM, Ferenc Kovacs wrote:
> never heard of that one before.
>
> for example, running
> for($i=0;$i<100;$i++){
> $foo="foo_".$i;
> ${$foo}->bar = 123;
> }
> echo "done";
>
> gives me 100 E_STRICT, but still executes just fine and prints "done" at
> the end.
> the onl
Greetings.
>>
The main problem arises from the ambiguity for $array[-1] for arrays.>>
But this is easily solvable: just introduce a slice operator.
>>
>>
$array[:-1] and the ambiguity is gone.
>That would return an array
containing the last item as the sole member, >not the last item
itsel
2012/9/3 Lester Caine :
> more ... try/catch always seems like 'I can't be bothered so just do this if
> you can' where it would be much tidier if file_put_contents(); was written
> so it simply finished with an error if it has a problem?
Hm. I want to bring in some thoughts.
Perhaps I have not t
2012/9/4 Rasmus Lerdorf :
> On 09/03/2012 04:31 PM, Alex Aulbach wrote:
>> 2012/9/4 Gustavo Lopes :
Following this logic, we'd have to convert all E_NOTICE and E_STRICT to
fatal errors or exceptions - they are usually produced by programming
errors and aren't meant to be caught by su
On Tue, Sep 4, 2012 at 6:31 PM, David Zülke wrote:
> On 03.09.2012, at 09:37, Jannik Zschiesche wrote:
>
> > The main problem arises from the ambiguity for $array[-1] for arrays.
> > But this is easily solvable: just introduce a slice operator.
> >
> > $array[:-1] and the ambiguity is gone.
>
> T
Hello all,
I'm opening the vote for the simplified password hashing API indicated here:
https://wiki.php.net/rfc/password_hash
Please vote,
Thanks,
Anthony
>
>
> Using third party code - joomla - only difference between working and not
> working is switching E_STRICT on. With display_errors=off one gets a white
> screen. I was not surprised as I've had this all the way through with code
> from many sources. Yes a lot of the time you just get the error
Peter Lind wrote:
From php.ini:
; display_errors
; Default Value: On
; Development Value: On
; Production Value: Off
In a production environment with display_errors off, E_STRICT doesn't
crash anything. Actually, even with it on, it doesn't crash anything -
shitty code does, by creating n
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine wrote:
> Pierre Joye wrote:
>
>> On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
>>
>> >??? OH YES IT DOES !!!
>>> >MANY times I get a a few lines of text on a white screen ...
>>> >Switch off E_STRICT and everything works fine ... as it was on P
On 4 Sep, 2012, at 3:59 AM, Stas Malyshev wrote:
> Hi!
>
>> The terminology "negative indexing" seems to imply that the feature
>> should work with arrays. To restrict it to just strings might involve
>> creating a term one would only associate with strings.
>
> I do not see any way to change
On 4 September 2012 15:09, Lester Caine wrote:
> Pierre Joye wrote:
>>
>> On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
>>
>>> >??? OH YES IT DOES !!!
>>> >MANY times I get a a few lines of text on a white screen ...
>>> >Switch off E_STRICT and everything works fine ... as it was on PHP5.2
Am Dienstag, 4. September 2012 um 15:09 schrieb Lester Caine:
> I keep being told that there is nothing wrong with E_STRICT, and again
> someone
> has said that it does NOT cause crashes. I beg to differ here - IT DOES!
> Now if you are saying that I need to document these crashes as they SHOULD
Pierre Joye wrote:
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
>??? OH YES IT DOES !!!
>MANY times I get a a few lines of text on a white screen ...
>Switch off E_STRICT and everything works fine ... as it was on PHP5.2
If you have any doubts about how to configure your development or
hi Lester,
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine wrote:
> ??? OH YES IT DOES !!!
> MANY times I get a a few lines of text on a white screen ...
> Switch off E_STRICT and everything works fine ... as it was on PHP5.2
If you have any doubts about how to configure your development or
produc
Sherif Ramadan wrote:
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine wrote:
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant?
And
how many are still requiring E_STRICT switched off in PHP5.4?
This is a development and very useful. PHP does not enforce
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine wrote:
> Pierre Joye wrote:
>>>
>>> How many of the major PHP user projects ARE currently strict compliant?
>>> And
>>> >how many are still requiring E_STRICT switched off in PHP5.4?
>>
>> This is a development and very useful. PHP does not enforce this
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant? And
>how many are still requiring E_STRICT switched off in PHP5.4?
This is a development and very useful. PHP does not enforce this mode.
And like any other errors, it only ends in your logs.
But this has
On 03.09.2012, at 09:37, Jannik Zschiesche wrote:
> The main problem arises from the ambiguity for $array[-1] for arrays.
> But this is easily solvable: just introduce a slice operator.
>
> $array[:-1] and the ambiguity is gone.
That would return an array containing the last item as the sole me
hi,
On Tue, Sep 4, 2012 at 11:32 AM, Lester Caine wrote:
> How many of the major PHP user projects ARE currently strict compliant? And
> how many are still requiring E_STRICT switched off in PHP5.4?
This is a development and very useful. PHP does not enforce this mode.
And like any other errors
Gustavo Lopes wrote:
Second, E_STRICT exists to encourage good OOP practices. There is a lot of code
that generates E_STRICT that does what it was intended to do (ask Lester). By
definition, code that's not supposed to generate E_STRICT messages but does is
buggy, but the fact that some code rais
On 2012-09-04 18:36, Stas Malyshev wrote:
Hi!
The problem is that the only formal definition of the language _is_ the
parser - there's no grammar outside
zend_language_scanner.l/zend_langauge_parser.y.
I'm not sure - why exactly is it a problem here? I can understand how
having such document
On Tue, 04 Sep 2012 01:27:12 +0200, Stas Malyshev
wrote:
to be gained vs. the additional risk. And there is little to no benefit
in a model where rewinding a closed iterator is allowed, so the
threshold for acceptable risk is very low. This is not a difficult case
at all, IMHO.
We are discu
Hi!
Given many discussions on the list about changing stuff in PHP, I'd like
to bring everybody's attention to comment by Linus Torvalds in this
topic: https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk
It talks about Linux kernel and discussion has next to nothing to do
with PHP, bu
51 matches
Mail list logo
