Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 thought only developers are subcribed to this list. To be serious: nope, it is perfectly valid to write your own modul to extend or change the functionality of drupal, and it does provide a pretty huge amount of infrastructure to do that (this is what every module use). From the development point of view, drupal like zend was not a method of working I could get on with. I did have a go. Hacking the configuration to get around this particular problem is a doddle ... just not something that the majority of the drupal users would be able to tackle though? In reality a large proportion of the on-line use of PHP is probably by users of secondary layers such as Joomla and Drupal and while they do seem to be heading in the right direction, there does seem to be a level of confusion at their end on just how to handle the differences since 5.2 ? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 just click together modules, written by others. > > > Actually Jan - Rasmus is right here - we just have to fix these applications to bypass problems. It's just a mater of someone who knows how to advancing the information. But it would be nice if projects like Drupal would indicate what they plan to do to bring their code in line with PHP's current 'standards'? Or if not, simply provide the configuration necessary for it to run without problems on each version of PHP? > > I have no problem with it being up to the projects to have to bend to the changes in PHP, my problem is that some of these bends are not totally thought out up front and are resulting in a lot of unnecessary work simply to stand still. generators are a case in point ... why did nobody who understands the fine detail spot the problem of hidden exceptions? Is it now a done deal that we have to live with these new ones now, or will an error based provision be made? > > It may take some time for me to go through ALL the white screen crashes I've been creating to cross check their actual cause, but without competent hand holding correcting mistakes like this, things are going to get missed. That IS all I have been asking for and the internals list is the only place where these questions get competent support. Although even here navigating the side issues can be interesting? > Could you stop changing subjects please? For this issue, fixing the issue for drupal would be easy, but usually for a project with that size needs some time to migrate to a new version, and AFAIR drupal versions are not guaranteed to be supported for php versions which weren't supported when the drupal version was released(I remember similar issues when php 5.3 was released.). Maybe this will change, as we plan to pump out new versions more frequently than them. Generators are a different topic. Yield is a language construct but it is involving an oop component to so it's job. Some people from the "core should nevet throw exceptions" group didn't noticed this and those who did was fine with a generator class method throwing an exception. As Stas mentioned it would be nice having more voters participating/reviewing changes.
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 by others. > > Jan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Oh, I thought only developers are subcribed to this list. To be serious: nope, it is perfectly valid to write your own modul to extend or change the functionality of drupal, and it does provide a pretty huge amount of infrastructure to do that (this is what every module use).
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 write any code. You just click together modules, written by others. Actually Jan - Rasmus is right here - we just have to fix these applications to bypass problems. It's just a matter of someone who knows how to advancing the information. But it would be nice if projects like Drupal would indicate what they plan to do to bring their code in line with PHP's current 'standards'? Drupal has four options for running under 5.4: 1. Turn E_STRICT off by default 2. Turn E_STRICT on by default 3. Do not mess around with system settings 4. Implement their own error_reporting setting, completely configurable (1) is not exactly bringing drupal in line with the current standards. It is a workaround. (2) and (3) will lead to loads of issues in those thousands of modules. (4) seems to me the only reasonable way out. Or if not, simply provide the configuration necessary for it to run without problems on each version of PHP? That would be (4) imo. However, there is no sign at all that the issue has ever attracted the full attention of one of the core developers. If you look at http://drupal.org/node/1267246 the current choice for drupal8 seems to be (3). "Needs backport to drupal7" ... I will leave it with this, because it is way off topic in the internals list. ACTUALLY Jan - This is exactly the sort of confusion that I'm finding on other projects! Configuring their own error_reporting setting in the config is exactly what a lot of projects do. It's ACTUALLY what caused my initial problems because I did not pick up early on that the setting was being overriden in one of the libraries I was loading! I wasn't getting errors because e_strict was being deliberately disabled. But my point here is that it is the projects attitude to e_strict that is important. http://drupal.org/node/348448 flags that for Drupal 8 everything should be clean, but that it's not been enforced on Drupal 7. However a very quick scan of their documentation does not find any specific reference to that in their coding standards. Joomla seems to be in the same state - everything from version 1.6 should be compliant, but that was not what I was finding. I still have to recreate my own crash problem with that - my current 5.4 setup IS just creating reams of error reports and clobbering performance. The client has let me switch e_strict on, but obviously I have something different on the production machine to the development setup. You indicated that you switched back to PHP5.3 and personally I think many people are not even moving from PHP5.2 because they have working setups and don't want to break things. Yes we can hide the problems by the right setting in php.ini, or in the project configuration, but what we need to be supporting is the move to make legacy code complaint, or provide an workable upgrade path. But when core php material such as PEAR has not addressed the problem how can we expect projects that are reliant on it to comply? OK it's not internals problem - but it is only the people who fully understand what is going on internally that can review what is going on in userland, correct misconceptions and ensure that the correct practices are being followed? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
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, "potential" was the focal point of my response (sometimes I type faster than I can proof, sorry :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
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.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
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 intuitive guesses fail." > > So, I'm cautious about the premise that this will/could lead to an > overall improvement in performance compared to the current > implementation, a caution that the RFC spoke to very clearly. This is probably why the section in the RFC is so small . . . :) --- It seems to me to be a very wise decision to use an AST but good decisions carried out poorly can be more harmful than helpful. We need to do this correctly. I hope this discussion will be helpful in this regard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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. >> You just click together modules, written by others. > >Actually Jan - Rasmus is right here - we just have to fix these applications >to >bypass problems. It's just a matter of someone who knows how to advancing the >information. But it would be nice if projects like Drupal would indicate what >they plan to do to bring their code in line with PHP's current 'standards'? Drupal has four options for running under 5.4: 1. Turn E_STRICT off by default 2. Turn E_STRICT on by default 3. Do not mess around with system settings 4. Implement their own error_reporting setting, completely configurable (1) is not exactly bringing drupal in line with the current standards. It is a workaround. (2) and (3) will lead to loads of issues in those thousands of modules. (4) seems to me the only reasonable way out. >Or if not, simply provide the configuration necessary for it to run without >problems on each version of PHP? That would be (4) imo. However, there is no sign at all that the issue has ever attracted the full attention of one of the core developers. If you look at http://drupal.org/node/1267246 the current choice for drupal8 seems to be (3). "Needs backport to drupal7" ... I will leave it with this, because it is way off topic in the internals list. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
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 response.) As should be obvious from my post, if this approach lead to increased performance, I would be all for it. 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 intuitive guesses fail." So, I'm cautious about the premise that this will/could lead to an overall improvement in performance compared to the current implementation, a caution that the RFC spoke to very clearly. My point is that, if there is an increase in the resources required, that is a really big deal. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
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 PHP very unique amongst languages, so there is perhaps a reason to be different here. Python also generates opcodes if you were to run it on CGI on request. However, like PHP will be able to when APC becomes default and ready enough, it caches them. The disadvantages of the AST approach are noted as the potential for increased resource requirements. When viewed in the RFC, the brevity of the section and the visual weight of its contents perhaps understates just how much of a big deal this could be. PHP as a web technology is run on a myriad of servers and processes a huge amount of requests every second across the world. Adding even a couple cycles to every request is a very big deal in the scheme of things, especially when we live in an age where many other industries are making great efforts to reduce resources required for goods/services. APC will make things faster, though, you're missing that. And optimisations, which an AST would help, would make it even faster. There was some mention of caching to alleviate the potential issues, and this could bring the cost down, perhaps even saving cycles in the long run. Or, perhaps some brilliant work on the processing could yield significant resource savings compared to the single-pass approach. My point is that I'm all for improving the PHP internals so as to facilitate future work on the core. However, these considerations must be carefully weighed against the resource footprint PHP now has, and the hope of continuing to make reasonable strides to reduce that footprint. Asking a few core developers to use more resources to handle hacks, quirks, and decoupling technical issues CAN be the preferred alternative if there are real savings in server resources used worldwide. That's not to say this area of work should be avoided. Rather, I am saying that I hope any work in this area would give the potential for additional resource usage very serious consideration. Adam -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
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 nice to get a few comments from other core devs on this. 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 PHP very unique amongst languages, so there is perhaps a reason to be different here. The disadvantages of the AST approach are noted as the potential for increased resource requirements. When viewed in the RFC, the brevity of the section and the visual weight of its contents perhaps understates just how much of a big deal this could be. PHP as a web technology is run on a myriad of servers and processes a huge amount of requests every second across the world. Adding even a couple cycles to every request is a very big deal in the scheme of things, especially when we live in an age where many other industries are making great efforts to reduce resources required for goods/services. There was some mention of caching to alleviate the potential issues, and this could bring the cost down, perhaps even saving cycles in the long run. Or, perhaps some brilliant work on the processing could yield significant resource savings compared to the single-pass approach. My point is that I'm all for improving the PHP internals so as to facilitate future work on the core. However, these considerations must be carefully weighed against the resource footprint PHP now has, and the hope of continuing to make reasonable strides to reduce that footprint. Asking a few core developers to use more resources to handle hacks, quirks, and decoupling technical issues CAN be the preferred alternative if there are real savings in server resources used worldwide. That's not to say this area of work should be avoided. Rather, I am saying that I hope any work in this area would give the potential for additional resource usage very serious consideration. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 - Rasmus is right here - we just have to fix these applications to bypass problems. It's just a mater of someone who knows how to advancing the information. But it would be nice if projects like Drupal would indicate what they plan to do to bring their code in line with PHP's current 'standards'? Or if not, simply provide the configuration necessary for it to run without problems on each version of PHP? I have no problem with it being up to the projects to have to bend to the changes in PHP, my problem is that some of these bends are not totally thought out up front and are resulting in a lot of unnecessary work simply to stand still. generators are a case in point ... why did nobody who understands the fine detail spot the problem of hidden exceptions? Is it now a done deal that we have to live with these new ones now, or will an error based provision be made? It may take some time for me to go through ALL the white screen crashes I've been creating to cross check their actual cause, but without competent hand holding correcting mistakes like this, things are going to get missed. That IS all I have been asking for and the internals list is the only place where these questions get competent support. Although even here navigating the side issues can be interesting? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
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 down to produce those opcodes, but not the opcodes themselves. Would tools like XDebug, APC, Zend PHP encoder (or whatever that's called this week), etc. be compatible out of the box, or would changes need to be made to them? Compatible, I think. Although I don't know if in the process some might be changed, but I would expect no big changes. -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
> 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 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? Would tools like XDebug, APC, Zend PHP encoder (or whatever that's called this week), etc. be compatible out of the box, or would changes need to be made to them? Also, here is a potential starting point if you're less allergic to OCaml than I am: https://github.com/facebook/pfff S
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 malfunctioning and not PHP then you should fix your application. If you have problems with that you can seek help on php-general or any other forums out there. In any case, I don't see how screaming about it here is going to lead to anything useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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_STRICT. Lester already > mentioned one scenario: ISP's tend to install PHP with the default > settings without the possibility to change them. Just call error_reporting() at the beginning of your script. It doesn't matter what your ISP has set there. You are in total control from userland. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Moving to an AST-based parsing/compilation process
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 the text
'set_error_handler(' just to be sure this isn't a possible cause?
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 install PHP with the default settings without the possibility to change them. Another scenario is the one that a framework or CMS overrides the php.ini settings. Quote from the bootstrap.inc of drupal7: // Enforce E_ALL, but allow users to set levels not part of E_ALL. error_reporting(E_ALL | error_reporting()); For the sake of argument I changed our development server from PHP 5.3.16 to PHP 5.4.6. I immediately got confronted with warnings like "Warning: Illegal string offset 'field' in EntityReference_SelectionHandler_Generic_user->entityFieldQueryAlter()" I know it is very bad coding in drupal7's bootstrap.inc. Read the comments at http://drupal.org/node/1267246 and you'll see I am not alone. Nevertheless, I am not interested in warnings like the one above from one of the many modules in drupal7. But I cannot turn off E_STRICT in drupal7 without changing bootstrap.inc manually. And that is the last thing I want to do. So I am changing our development server back to PHP 5.3.16. The E_STRICT change prevents me from upgrading to PHP 5.4. In my case I can just wait for a patch of bootstrap.inc. But users on a shared hosting server may have no way to avoid these warnings. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 is only Smarty3 The changes in this area was one reason for not upgrading to Smarty3. I don't think Smarty2 has an exception handler. But it my be that all of the templates have to be reworked for Smarty3 simply to take advantage of some of the other 'strict' updates in it. And, ADOdb can, too: http://phplens.com/lens/adodb/docs-adodb.htm#errorhandling Only using in-line error handling so adodb-exceptions.inc.php is not loaded. I'm not saying they're your issues, but just another spot to check. Joomla doesn't use either anyway, and neither do a number of the other sites I've been porting, but we still get problems. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 >> see I'm checking to make sure the error level matches, just as Ferenc >> pointed out (what a forgetful old man I am.) >> >> So, I think this could still be causing the issue and it's something >> worth exploring on Lester's part. > > > 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 And, ADOdb can, too: http://phplens.com/lens/adodb/docs-adodb.htm#errorhandling I'm not saying they're your issues, but just another spot to check. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 Ferenc pointed out (what a forgetful old man I am.) So, I think this could still be causing the issue and it's something worth exploring on Lester's part. 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. Switching back to old code to at least prove to myself I WAS getting crashes, I got a white screen within half an hour of configuring an old setup. Knowing that I did get crashes when dealing with 'static' functions, I started there, and now that other things have been pointed out, the problem in that case is ALL parts of the codebase need to be updated at once. Otherwise fixing things in one library breaks other code. It may well be that having got a clean strict PHP5.4 setup I've then been getting problems when porting additional sites over. I KNOW that I've had a setup where simply switching E_STRICT on and off gives white screens, and I did have that situation a couple of weeks back. Simply adding and removing a custom error_reporting() got me working or not, but that was trying to run Joomla on a PHP5.4 setup with a strict clean PEAR and other libraries. So I may well have been suffering from 'cross contamination'. But this is the whole point ... getting a clean setup that will run older sites is a right pain :( I need to get back to a PHP5.2 setup which works and then cross check what is failing on the PHP5.4 setup. But none of this is productive work. Nothing I've moved over in the last 3 months have worked 'out of the box', all have had to have something done to get them running again. One thing I think is clear is that I need to avoid using a central PEAR until such time as everything is stable. Certainly that is this initial crash problem, but I know there were more problem areas. I am regretting giving in to the pressure to upgrade the shared codebase to be strict compliant. I think that I'd much further forward simply ignoring it altogether and done my own thing. Certainly some third party stuff left is not going to be work with E_STRICT any time soon :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 collects error >> > info and then throws an exception (as has been detailed in various >> > blog posts as one manner of unifying the errors), this would cause the >> > trouble you're seeing. >> >> 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 in E_ALL or not, nor whether display_errors is on or >> off. It would have to do with the custom error handler blowing up on one >> specific E_STRICT, which I find rather unlikely. >> > > Don't forget that many error handlers check the error level against the > currently set error_reporting (so that they won't be executed on supressed > errors and such). > AFAIR we even promote that implementation in our error handler example in > our docs. > That would mean that the error handler main logic is only executed if > E_STRICT is in the error_reporting. 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 Ferenc pointed out (what a forgetful old man I am.) So, I think this could still be causing the issue and it's something worth exploring on Lester's part. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 detailed in various > > blog posts as one manner of unifying the errors), this would cause the > > trouble you're seeing. > > 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 in E_ALL or not, nor whether display_errors is on or > off. It would have to do with the custom error handler blowing up on one > specific E_STRICT, which I find rather unlikely. > Don't forget that many error handlers check the error level against the currently set error_reporting (so that they won't be executed on supressed errors and such). AFAIR we even promote that implementation in our error handler example in our docs. That would mean that the error handler main logic is only executed if E_STRICT is in the error_reporting.
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 in E_ALL or not, nor whether display_errors is on or > off. It would have to do with the custom error handler blowing up on one > specific E_STRICT, which I find rather unlikely. > > -Rasmus Whoops, you're right! I forgot that the custom error handler is called regardless of error reporting. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 errors), this would cause the > trouble you're seeing. 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 in E_ALL or not, nor whether display_errors is on or off. It would have to do with the custom error handler blowing up on one specific E_STRICT, which I find rather unlikely. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 time you just get the error messages, but a white screen crash has been the norm most of the time so leaving display_errors=on helps while fault finding on the development systems. usually most people set display_errors=off but log_errors = on and just check the logfiles for errors. there is no point bothering your users with messages they won't understand or could be able to do anything about, plus it is usually a security vulnerability (Information Leakage). I know all about that side of things ... now I just need to recreate what has been giving me white screens ... having spent a year getting rid of them. GOT IT ... Or at least a white screen, but of cause now that some things have been pointed out then it's obvious what is going on! 12 months on I can see things differently! It is a fatal 'PHP Fatal error: Cannot make static method ... non static' at least on this white screen. The base library has some 'static' references but the descendent classes don't. Having updated some core libraries, the rest of the code is out of sync. But I've managed to pick up a back version that is full of 'deprecated' errors as well. So I need to scroll forward a bit so that I only have E_STRICT differences. I'm fairly sure now that it's the missing 'static' references in PEAR that start some of the confusion on this. I needed a clean strict version of PEAR as the base classes for some areas. And then make sure I don't access that with other websites that have yet to be 'upgraded'. Joomla may be failing over if it's picking up the wrong central libraries? Not having using it before I'll need to check what is picking up centrally. And the error log growing at 40 time the size of the access log is not encouraging from a maintenance viewpoint :( Hiding errors is all very well, but the error log still needs to be usable in production. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 only explanation that I can think of is that you have a custom error
> handler somewhere in your code, which somehow does something unexpected
> (exits the script execution or does something like an infinite recursion
> which segfaults/OOMs your application.
> if you still think that it isn't the case, then please open an issue on
> bugs.php.net with a reproduce script, as this would be clearly a bug.
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 errors), this would cause the
trouble you're seeing.
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
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 itself. Which suggests a solution, namely either use another symbol or else attach to the colon a different meaning. Or, we can forget about applying this feature to arrays and hope that users will understand that this is a feature that only applies to strings and use a simple negative offset.SL
Re: [PHP-DEV] Exceptions Vs Errors
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 the right words to describe what I mean, but there are 3 things which come in my mind when PHP may switch the error-handling to any kind of exceptions: 1. Current error-handling has it's advantages. Ideal for short programs. I don't wanna miss it. I need to ignore errors completely. 2. I think - prove me wrong :) - it is not possible to change the hole error-handling from one PHP-version to another, especially when the behavior changes so entirely. I think it will take some time. Maybe we have to live with a mixture (new exceptions and old error-handling) for some time? 3. Why not having this as concept? Maybe it's a good strategy to enable both: current error-handling and having exceptions? The rest is logic: When I want to enable to handle an exception like an PHP-error, I need to tell PHP during the creation of the error, that it should not handle it like an exception. Ok, ok, as Rasmus correctly mentioned, uncaught exceptions are by definition fatal. But isn't catching an exception not like "I know how to handle it?" And when I know how to handle it, couldn't I handle it in the exception directly? More questions than answers so far. -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
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 surrounding code (actually, can't). But I don't see anybody benefiting from this - as I don't see anybody benefiting from generator that will explode your application if you touch it twice. >> >> Nobody is forced to handle an notice-exception like a fatal exception. >> A notice-exception can be created write something into an error-log >> and tells PHP not to handle it any more (destroys itself). Could be >> all done in the construction of the exception. >> > > First, you got the quoting wrong. Please be more careful with that. Sorry, was written from very old laptop which has problems, when I mark text. > And second, huh? Uncaught exceptions are by definition fatal. There is > no such thing as a notice exception. If we go down that road refer to my > email describing condition error systems. Longer term I think a > condition system would make a lot of sense for PHP, but we definitely > don't want to introduce some sort of bastard non-fatal exception. Maybe I had not the right words to describe, what I mean: I would like to see both worlds (current error-handling and exceptions) in PHP - just as I need it. Your proposal sounds quite interesting. For example: If an SQL-query fails, the query itself isn't normally very interesting (it's wrong, ok). I need to know where it was created and how. The error is not in the database, it's most times in the PHP-program... -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
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. > > That would return an array containing the last item as the sole member, > not the last item itself. > Assuming Python syntax, that returns the array of items up to (not including) the last item actually, an array containing the last item would be $array[-1:] - I wouldn't mind slice syntax :) nifty stuff ... maybe too nifty. > > David > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- -- Tjerk
[PHP-DEV] [VOTE] Add simplified password hashing API
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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
> > > 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 messages, > but a white screen crash has been the norm most of the time so leaving > display_errors=on helps while fault finding on the development systems. > > usually most people set display_errors=off but log_errors = on and just check the logfiles for errors. there is no point bothering your users with messages they won't understand or could be able to do anything about, plus it is usually a security vulnerability (Information Leakage). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 notices and then using header() calls afterwards to create redirects. Solution: fix your server. Fix your code. It worked for the rest of us. 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 messages, but a white screen crash has been the norm most of the time so leaving display_errors=on helps while fault finding on the development systems. Most of the production strict fixes have now been committed on my own code, but I think I've still got an older 5.2 machine that still has the earlier code. I THINK one of the crashes comes when using $this in a static function. Certainly a lot of the recoding has been splitting a lot of these out to two separate functions but I've been seeing white screens for the past year as I work through third part code and to be honest since ALL I was changing as E_STRICT I had not looked much closer :( Other than e_strict and fatal as the last message visible. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 PHP5.2 >>> >> If you have any doubts about how to configure your development or >> production servers, how to use logs or how to effectively debug php >> applications, please ask questions on php-general or php-setup mailing >> lists. >> >> Thanks for your understanding, >> > Butt out Pierre ... > > 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! > never heard of that one before. for example, running bar = 123; } echo "done"; gives me 100 E_STRICT, but still executes just fine and prints "done" at the end. the only explanation that I can think of is that you have a custom error handler somewhere in your code, which somehow does something unexpected (exits the script execution or does something like an infinite recursion which segfaults/OOMs your application. if you still think that it isn't the case, then please open an issue on bugs.php.net with a reproduce script, as this would be clearly a bug. > Now if you are saying that I need to document these crashes as they SHOULD > not be happening then I'll roll things back and start doing that, I would be generally surprised if you are serious about not knowing about that triggering an E_STRICT shouldn't blow up your php. > but *I* thought that these crashes were simply a known effect of using > E_STRICT? nope. E_STRICT is currently the least serious/grave notice that the we have in php(see the initial documentation at http://php.net/manual/en/migrating5.errorrep.php), and until 5.4, it wasn't part of E_ALL at all (see http://www.php.net/manual/en/migration54.other.php ). which made some people bashing the project, that we call something E_ALL which doesn't include everything. so it was changed with 5.4, so > And so I followed the directions, and switched E_STRICT off. On production > machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white > screen crashes using older code ... as far as I was concerned that was a > known fact. Switch it off and everything runs fine! > > would be nice if you could come up with a small snippet/stand alone script to reproduce the issue and attach it to a bugreport. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
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 behavior of $array[-1] that would make > sense. So either only strings get it or nobody gets it. I suppose one could still extend ArrayAccess and have their own negative indices support for arrays :) > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 >> >> If you have any doubts about how to configure your development or >> production servers, how to use logs or how to effectively debug php >> applications, please ask questions on php-general or php-setup mailing >> lists. >> >> Thanks for your understanding, > > Butt out Pierre ... > > 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 > not be happening then I'll roll things back and start doing that, but *I* > thought that these crashes were simply a known effect of using E_STRICT? And > so I followed the directions, and switched E_STRICT off. On production > machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen > crashes using older code ... as far as I was concerned that was a known > fact. Switch it off and everything runs fine! > >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 notices and then using header() calls afterwards to create redirects. Solution: fix your server. Fix your code. It worked for the rest of us. Regards Peter -- WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 > not > be happening then I'll roll things back and start doing that, but *I* thought > that these crashes were simply a known effect of using E_STRICT? And so I > followed the directions, and switched E_STRICT off. On production machines of > PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen crashes > using > older code ... as far as I was concerned that was a known fact. Switch it off > and everything runs fine! Hi Lester, did you actually check the error messages or did you stop with the white screen? If it is the later one, please try to reproduce such issues, so that one can investigate it further. Because the current situation is: - you say: "it crashes" - somebody else says: "it doesn't" And I don't think that this will lead anywhere... Cheers Jannik
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 production servers, how to use logs or how to effectively debug php applications, please ask questions on php-general or php-setup mailing lists. Thanks for your understanding, Butt out Pierre ... 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 not be happening then I'll roll things back and start doing that, but *I* thought that these crashes were simply a known effect of using E_STRICT? And so I followed the directions, and switched E_STRICT off. On production machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen crashes using older code ... as far as I was concerned that was a known fact. Switch it off and everything runs fine! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 production servers, how to use logs or how to effectively debug php applications, please ask questions on php-general or php-setup mailing lists. Thanks for your understanding, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 this mode. And like any other errors, it only ends in your logs. But this has been told to you a good dozen of times in the past, and it is really getting ridiculous to have to explain that over and over. And the point of YOUR comments? With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash if they have not been 'converted'! E_STRICT can't crash you program. It's just like an E_WARNING or E_NTOICE level error. It's non-fatal. It does not inhibit the execution of code. ??? 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 The QUESTION is a perfectly valid one ... especially when I've just hit yet another current project that we have to make sure to disable E_STRICT when they get transferred to a PHP5.4 machine! I have no doubt a lot more will also be affected and so knowing the right answers is important. As perhaps is understanding the reason some projects are not converting code? What exactly is the question that you're posing to PHP Internals? An audit of how much code doesn't follow strict standards? Probably a lot. I've seen plenty of it in production myself and among them even the most popular PHP frameworks. Having tested Joomla on PHP 5.4 before a switch to production I recall seeing an actual drop in performance due to the sheer number of E_DEPRECATED and/or E_STRICT errors that the code produced. That is one which was white screening for me, and all I was trying to do was a favour for some one. A quick hack of the config file and we were working again, but certainly some modules in Joomla are not save when used with E_STRICT set! However, none of that prevented the code from running (or "crashing" as you say). All you have to do is change the error_reporting directive if you chose to ignore those errors for the time being. You simply don't have display_errors on in production anyway so the worst possible outcome here is that you end up with an error log stuffed with those errors. Nothing critical here. This is not even a minor concern for most code basis that exhibit this problem to a great degree because the majority of them aren't willing to upgrade to 5.4 or have realized the problem by now and are fixing their code. The 'concern' is that ISP's are following the recommendations, and using the default production setup, so E_STRICT is on - PLEASE LEAVE IT OFF should be the standard! While the preference on PHP5.4 may be to force people to comply, the reality is that this is a switch which it's more likely needs switching off in production simply because user land has no idea how to handle the problems yet. And I'll keep banging on until what is distributed from the php.net site actually works on a current default install ... The userland problem is a trivial issue. All they have to do is turn display_errors off in production as is recommended and is the default anyway. There is nothing major here to hold you back other than yourself. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 mode. >> And like any other errors, it only ends in your logs. >> >> But this has been told to you a good dozen of times in the past, and >> it is really getting ridiculous to have to explain that over and over. > > > And the point of YOUR comments? > With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash > if they have not been 'converted'! > E_STRICT can't crash you program. It's just like an E_WARNING or E_NTOICE level error. It's non-fatal. It does not inhibit the execution of code. > The QUESTION is a perfectly valid one ... especially when I've just hit yet > another current project that we have to make sure to disable E_STRICT when > they get transferred to a PHP5.4 machine! I have no doubt a lot more will > also be affected and so knowing the right answers is important. As perhaps > is understanding the reason some projects are not converting code? > What exactly is the question that you're posing to PHP Internals? An audit of how much code doesn't follow strict standards? Probably a lot. I've seen plenty of it in production myself and among them even the most popular PHP frameworks. Having tested Joomla on PHP 5.4 before a switch to production I recall seeing an actual drop in performance due to the sheer number of E_DEPRECATED and/or E_STRICT errors that the code produced. However, none of that prevented the code from running (or "crashing" as you say). All you have to do is change the error_reporting directive if you chose to ignore those errors for the time being. You simply don't have display_errors on in production anyway so the worst possible outcome here is that you end up with an error log stuffed with those errors. Nothing critical here. This is not even a minor concern for most code basis that exhibit this problem to a great degree because the majority of them aren't willing to upgrade to 5.4 or have realized the problem by now and are fixing their code. > While the preference on PHP5.4 may be to force people to comply, the reality > is that this is a switch which it's more likely needs switching off in > production simply because user land has no idea how to handle the problems > yet. And I'll keep banging on until what is distributed from the php.net > site actually works on a current default install ... > The userland problem is a trivial issue. All they have to do is turn display_errors off in production as is recommended and is the default anyway. There is nothing major here to hold you back other than yourself. > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 been told to you a good dozen of times in the past, and it is really getting ridiculous to have to explain that over and over. And the point of YOUR comments? With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash if they have not been 'converted'! The QUESTION is a perfectly valid one ... especially when I've just hit yet another current project that we have to make sure to disable E_STRICT when they get transferred to a PHP5.4 machine! I have no doubt a lot more will also be affected and so knowing the right answers is important. As perhaps is understanding the reason some projects are not converting code? While the preference on PHP5.4 may be to force people to comply, the reality is that this is a switch which it's more likely needs switching off in production simply because user land has no idea how to handle the problems yet. And I'll keep banging on until what is distributed from the php.net site actually works on a current default install ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
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 member, not the last item itself. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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, it only ends in your logs. But this has been told to you a good dozen of times in the past, and it is really getting ridiculous to have to explain that over and over. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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 raises an E_STRICT does not signal, by itself, a bug. And in hindsight I'd say this was one of the worst decisions made in the past !!! Simply switching something off just to make code work again is just wrong how ever you look at it. This 'strict' stuff should have been handled with a bit more intelligence such as providing a report as to non-compliant code which picks up all the 'style differences' rather than having to work through layer after layer of errors. My converted code is messy and does now need a 'style tidy' clean-up. And I'm still not happy that what I AM doing the right things anyway! 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? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $obj->attr::method() is not allowed
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 might be useful and interesting (not useful and
interesting enough that for the last 10 years anybody bothered to do it
but still, I can imagine) - but how existence of such document would
solve your problem?
My problem? I'm not the one who wrote:
On 2012-09-04 03:18, Andrew Faulds wrote:
>
>
> Can't do this:
>
>self::$views[$path]();
>
> But I *can* do this:
>
>$x = self::$views[$path]; $x();
>
But I'm certainly among those who've raised this in the past. A quote
from https://wiki.php.net/rfc/fcallfcall
"What does not work currently is $foo→bar()() - since it is surprisingly
hard to tell parser it's not {$foo→bar}()() - which of course is not
what I want to do."
The complexity of the current grammar is working against development.
The developers of phc (http://www.phpcompiler.org/) ended up having to
write their own AST-based grammar (which may possibly serve as a
starting point for a grammar rewrite) because PHP's own parsing of even
simple expressions is so long-winded and unintuitive. That site gives a
couple of examples: (for 'printf("Hi!");' (27 nodes, including
"r_variable") and '$a->b->c' (26 nodes, including
"base_variable_with_function_calls")).
I don't see any relationship between the fact that implementation of
separate compiler required separate parser (which is only logical since
existing parser is built to suit the needs of existing compiler and not
whatever needs phc authors had) and the parser being "unintuitive". I
also do not see how the number of states the parser passes is a measure
of anything and why 27 should looks like a horrible number. There are a
lot of things that can happen in expression, in function call and in
function argument, the parser must understand it all.
>
Actually, looking at the parse tree the authors gave, I think there's a
bug in the diagram and there may only be 22.
How many of those things really are distinct, and how many are an
artefact of the implementation? To pick just one a recent example: why
is the $x in "foreach($array as $x)" such a different beast from the $x
in "$x = $array[0]" that the latter could be replaced by "list($a, $b)"
but the former couldn't?
For the arguments given by phc's authors, what their needs were (a
PHP->x86 assembly compiler), other use cases for a language
specification, and what they've done about it, I redirect you to the
site cited, since they know them better than I (having worked on it for
longer than I have). Mainly
https://www.cs.tcd.ie/publications/tech-reports/reports.07/TCD-CS-2007-47.pdf
rather than try to summarise them here and have questions directed at
the summary rather than the source (as has already happened).
As for r_variable, it's just an expression that is not writable (i.e.,
no printf("Hi")=1) - what's so strange about it?
Ah, so "r_variable" means "non-writable expression". Makes perfect
sense. Incidentally, "r_variable" expands to "variable", then to
"base_variable_with_function_calls", and _then_ to "function_call".
Then again, $a->b->c is _also_ an "r_variable", so does that mean I
can't write "$a->b->c = 1;"?
Morgan L. Owens
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Are exceptions allowed in php core?
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 discussing whether it should lead to the fatal error. I see no reason for that and declaring "it's not difficult" does not make a reason a bit clearer. There should be a reason for generating fatal error, and "this may be a bug" is not a reason enough, at least not in PHP, as long established practice in PHP clearly shows. Yes, we are. I am saying that "reason" is a balancing of factors: (1) whether the non-exception error behavior makes sense and (2) the extent it has legitimate uses on one hand and, on the other hand (3) the risk it introduces. Of course different languages balance these factors differently and PHP puts less emphasis on (3) -- I'm not trying to change that. There is no strict technical reason for most fatals in PHP too. Except maybe parser errors, you usually can abstain from doing whatever action would cause the fatal instead of raising the fatal. Calling function that does not exist or abstract method? Return NULL (like an invalid call btw). Returning null is a legitimate function return, and there's no value that can not be legitimately returned from an existing function. Moreover, since unlike empty iterator, not calling a function is not normal (iterators can be legitimately empty, but function can not be legitimately non-existing) fatal error is a proper response to it. Of course, if we used exceptions, there could be an exception thrown instead, which is the same thing more or less. Your distinctions here make no sense to me. I cannot understand how the first sentence is even an argument, but in any case you can also say, "Returning an empty set is a legitimate iterator return, and there's no set that cannot be legitimately returned from an existing iterator". There's also no meaningful distinction after. It boils down to what you consider "normal" and "legitimate", and for some reason you equate not traversing an iterator and replacing it with an empty one as "normal" and "legitimate", but not executing a function and replacing it with a null returning one abnormal and illegitimate. But I'm glad you think this way. It means that you accept that the criterion for raising a fatal is not simply "will we segfault if we do this?" or "can we continue parsing if we do this?", but it is instead more nuanced, requiring us to evaluate the "normality" and "legitimacy" of non-fatal behavior, as you put it. IMO, this is perhaps your strongest argument. But 1) that was a bad idea, 2) we're not really talking about the behavior of foreach(), we're talking about the behavior of specific methods that may or may not be called in the context of a foreach, in a hierarchy where exception throwing is well established. So it's not really analogous. Sorry, but again I have a feeling that you are not satisfied in general with how PHP handles errors and want much more strictness there. Which is completely fine, but I must again emphasize that doing it by sneaking exceptions here and there into the core is not the right way to do it. If you want to change how PHP behaves, it should be done as a language-level principle change, and not being done by altering bits of random patches to behave how the "strict" people like and inconsistently with how the rest of PHP behaves. I would be happy to discuss it, I have a lot of issues with current error handling too, but we can not just ignore the established principles. I think you're misrepresenting my position. I want strictness only in the cases where the alternative behavior fails the balancing test I mention above, a test you (at least to some extent) also support. In the other e-mail you say: So it basically comes to "it doesn't follow but E_NOTICE in fact should be fatal for those who prefer a stricter model because I had some code where it indicated a bug". That's exactly what I was talking about. [...] If however we want to keep the current nature of PHP, introducing fatal errors where it can be avoided only because it _may be_ a bug makes little sense - we have tons of situations where it may be a bug - just as you described with E_NOTICE and no fatal error there. My test is not whether it *may* be a bug, as I explained. Yes, E_NOTICEs *may* indicate a bug. But many times they will not (esp. on templates). Now, we may disagree on this, but I content that the situation we're discussing is *almost certainly* a bug. If we have a behavior that can be used in two contexts and it is not consistent with one of them, it is not good to point out it may be consistent with another. Not throwing exception in this case is consistent with all other PHP - nothing requires that generator or iterator would thr
[PHP-DEV] On BC and interfaces
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, but generic point about keeping the interfaces and importance of not serving one use case I think very important for all widely used platforms equally. I think the opinion of the author of one of the most successful platforms in recent history may be interesting to consider. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
