Re: [PHP-DEV] Memory warning hook
Can't you do this already? memory_limit can be fetched via ini_read, and together with memory_get_usage you should be able to check for this sort of thing. Admittedly having to parse memory_limit (which can be in various units) is not perfect. On Tue, Mar 5, 2013 at 1:23 PM, nat...@starin.biz wrote: As PHP applications are turning into large frameworks one of the issues arriving is memory management. One of the issues is that many frameworks use sophisticated caching techniques to make accessing the same data quickly, this improves speed it is at the cost of memory. Often the developer knows these areas that cache and often times already have functions in place to clear out the cache, however in the case where PHP is approaching or exceeds memory limits PHP runs the GC then dies if it cannot allocate enough memory. If we implemented memory warning triggers or user function that will be called before the GC is executed which allows the user to try and free up some memory on their own. This hopefully would give more flexibility to allowing these advanced caching techniques but at the same time allow the cache to be cleared out in case memory is getting low. Thoughts? Thanks, Software Developer Nathan Bruer -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Autoboxing Draft
comprising all old/compatibility stuff. == Advantages == - Cleanup of the language - Consistency and predictability improved a lot (also in constrast to possible userland classes - which would then all be slightly different) - No lacking backwards compatibility - Easier learning for new PHP programmers (beginners to PHP would be much more pointed to learning OOP than procedural programming) - Easier switching for programmers from Java to using PHP and vice versa (now that PHP grew very mature, attract the Java folks with the cool stuff PHP offers) - Little overhead (as far as I am aware) to implement - Nicer language syntax (see References) == Disadvantages == - I don't know how complicated it is to implement. So far we don't have any extensions for this on PECL, except for strong typing (see reference). From a theoretical point of view, it is just mapping. - There might be heaps of ways to implement, as the other autoboxing RFC offers one possiblity. Certainly we need discussion on the best way to implement. Maybe also autoboxing is the wrong word, as this RFC simply suggests to map primitive types to some objectual syntax. == References == This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle of nicer syntax. [[ http://php.webtutor.pl/en/2011/04/13/strong-data-typing-in-php-part-ii-autoboxing-and-indestructable-objects-english-version/]] implements a sort of userland autoboxing in PHP. [[http://www.php.net/manual/en/intro.spl-types.php]] is the documentation of PECL SPL_Types, which make strongly-typed classes for primitive types available. While they implement strong typing (if wanted), they do not offer syntax cleanup. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regarding BC bugs fixes and XKCD
... As the number of people who might do so decrements thanks to the attitude of the person wishing for it. On Wed, Feb 13, 2013 at 11:18 AM, Sherif Ramadan theanomaly...@gmail.com wrote: On Wed, Feb 13, 2013 at 11:04 AM, Aaron Holmes aa...@aaronholmes.netwrote: I'm sure many, if not all of you have seen this already. http://xkcd.com/1172/ It sounds awfully familiar to PHP Internal's attitude toward BC considerations for bug fixes, and perhaps offers some (albeit humorous) insight into why some things just need to be fixed. That's an excellent attitude! I'm all for fixing broken stuff. Now if only we can find more people that actually fix stuff and less people that have time to post xkcd comics? --- Sherif, The always happy, never grumpy guy... -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/gd/gd_ctx.c: In function '_php_image_stream_putc': error: 'struct gdIOCtx' has no member named 'data'
On Sun, Feb 10, 2013 at 2:50 PM, Dennis Clarke dcla...@blastwave.org wrote: Does this mean there is a fork of GD inside the php source tarballs and that the stuff I see at Tom Boutell's site is just something else ? I would like to know the answer to that myself. The gd project is currently maintained by the PHP community. I'm not sure if what's in the PHP tarballs is different from what's on bitbucket and to what degree. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Ruby's symbols
If symbols could use the sign bit or otherwise distinguish from typical integer
keys one would have some hope of meaningful debugging output. I don't think it
makes sense to mix integer keys and symbol keys but being able to differentiate
them for debugging purposes would be great. However since php arrays are sparse
anyway is there much of a win from integer keys in the first place?
Sent from my iPhone
On Jan 5, 2013, at 6:28 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi :-),
Nice proposal but I have few questions and remarks.
My first question is how to delete symbols? I don't know if it is useful or
not. We should discuss about that. Is `unset(:foo)` enough? How are they
handled by the GC?
Another question is: where are we able to use symbols? Is it allowed to write
`const FOO = :bar` for example? Or in a default argument value: `public
function f ( $x = :foo ) { … }`?
What kind of (arithmetical) operations are allowed on symbols?
You proposed to represent symbols as integers. Could it create conflicts? For
example: `$foo = [0 = 'bar', :baz = 'qux']`. What happens if `:baz` is set
to 0?
Finally, if my memory is good, a few months ago, some patches were updating
“constant strings” performances by representing them as “buffers”/“constants”
internally, no? Maybe I'm wrong, but it could be a middle-way solution if it
is not yet implemented (especially since we have strings dereferencing,
implementation could be ease).
My two cents :-).
Best regards.
On 05/01/13 15:07, Nikita Nefedov wrote:
I know I shouldn't write Ruby in the subject of a letter for php-internals
ML, but... Just wanted to ask, is anybody interested in this feature in PHP?
You can read about it here:
http://www.randomhacks.net/articles/2007/01/20/13-ways-of-looking-at-a-ruby-symbol
It can be implemented in PHP as a HashTable where key would be strings and
values would be unique identifiers (just incrementing long, can be tracked
with nNextFreeElement).
How it would work in userland?
If it would be proposal, I would divide it on two different (competitive)
proposals:
First, we could implement it so symbol expression would return an associated
integer.
(note that symbols are most often used as hash keys in ruby so my examples
are relying on it)
Example:
$foo = array();
$foo[:bar] = qwerty;
var_dump($foo);
// array(1) {
// [0] =
// string(6) qwerty
//}
var_dump(:bar); // int(0)
var_dump(:some_new_symbol); // int(1)
This is the easiest way, and I can implement it. But, it would be hard to
debug.
The second way - we can implement it as a new variable type, and the main
thing is that arrays will be able to take variables of symbol type as keys,
I know it sounds scary but it's not so hard actually.
I will drop the part about new variable type, the main thing is how
HashTables could work with symbols as keys.
We could change the type of nKeyLength (in Bucket) to signed integer (now
it's unsigned, I don't think we will miss something from that) and use it as
a flag: if it's -1 (less than zero) - then we know the symbol was used as a
key, there will be filled bucket.h member with a symbol identifier.
That way the above code will evaluate so:
$foo = array();
$foo[:bar] = qwerty;
var_dump($foo);
// array(1) {
// [:bar] =
// string(6) qwerty
//}
var_dump(:bar); // symbol(:bar)
var_dump(:some_new_symbol); // symbol(:some_new_symbol)
To make it clear, when retrieving an element by symbol from array, these
steps will be needed:
1. Get symbol identifier (ulong)
2. Get elements from array where bucket.h equals to this identifier
3. Iterate over those elements and find the one that has nKeyLength == -1
(actually we will iterate over pNext/pLast elements)
What symbols can give:
1. More convenient way to use it almost everywhere as a replacement for
strings and sometimes for constants. There's a lot of code that uses arrays
as a parameter-stores. For example, here's how you usually define a form in
Symfony2:
$builder
-add('title', 'text', array(
'label' = 'Album title'
))
-add('title_alias', 'text', array(
'label' = 'Album alias',
'required' = false,
'property_path' = 'properties.titleAlias'
))
-add('comment', 'text', array(
'label' = 'Comment',
'required' = false,
'property_path' = 'properties.comment'
))
-add('labels', 'text', array(
'label' = 'Musical labels',
'required' = false,
'property_path' = 'properties.labels'
))
-add('language', 'text', array(
'required' = false,
'property_path' = 'properties.language'
))
It could be improved this way:
$builder
Re: [PHP-DEV] PHP 5.3 - end of live schedule
Has APC's PHP 5.4.x support matured yet to the point where folks are comfortable there's no environment in which you really shouldn't run 5.3? On Mon, Dec 10, 2012 at 3:10 PM, Florian Anderiasch flor...@anderiasch.de wrote: On 10.12.2012 15:24, Johannes Schlüter wrote: On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote: To be honest, Debian isn't really the distribution I'm worried about. Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles off, it seems. RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is supposed to be out in the second half of next year, but history (and my own experience both in supporting users and dealing with vendors) suggests that RHEL users are slow to upgrade. Ubuntu won't have another LTS release until 2014. All those are interested in are critical/security fixes. Besides that the version is frozen. So for those I don't see a benefit to continue providing unrelated fixes. Yes, with RHEL 6.3 using 5.3.3 I don't see how doing anything besides going into bugfix mode is going to benefit those users, or is there a 6.4 planned? Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
(Really shouldn't run 5.4, rather) On Mon, Dec 10, 2012 at 3:52 PM, Tom Boutell t...@punkave.com wrote: Has APC's PHP 5.4.x support matured yet to the point where folks are comfortable there's no environment in which you really shouldn't run 5.3? On Mon, Dec 10, 2012 at 3:10 PM, Florian Anderiasch flor...@anderiasch.de wrote: On 10.12.2012 15:24, Johannes Schlüter wrote: On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote: To be honest, Debian isn't really the distribution I'm worried about. Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles off, it seems. RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is supposed to be out in the second half of next year, but history (and my own experience both in supporting users and dealing with vendors) suggests that RHEL users are slow to upgrade. Ubuntu won't have another LTS release until 2014. All those are interested in are critical/security fixes. Besides that the version is frozen. So for those I don't see a benefit to continue providing unrelated fixes. Yes, with RHEL 6.3 using 5.3.3 I don't see how doing anything besides going into bugfix mode is going to benefit those users, or is there a 6.4 planned? Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
Sure. I wasn't asking for myself but rather in the context of how close 5.3 is to being reasonable to deprecate. On Mon, Dec 10, 2012 at 3:55 PM, Pierre Joye pierre@gmail.com wrote: hi, On Mon, Dec 10, 2012 at 9:52 PM, Tom Boutell t...@punkave.com wrote: Has APC's PHP 5.4.x support matured yet to the point where folks are comfortable there's no environment in which you really shouldn't run 5.3? For most apps it should work fine now. There are one or two issues in some edge cases but we see less and less reports about it. But good testing with your apps should be a must do before going wild :) -- Pierre @pierrejoye -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recycle PHP Log
So? Non-administrative users should not be worrying about rotating log files. Shared services have administrators who are keenly interested in not running out of disk space due to silly things like log files and provide rotation of them (or if not, you have a choice of better providers who do). On Tue, Oct 30, 2012 at 1:33 PM, Raymond Irving xwis...@gmail.com wrote: Most of these utilities require admin user access to the server. For example, Logrotate is normally run as a daily cron job There are a lot of shared services that will not allow users to install or run certain jobs. How difficult will if be to add this feature to PHP? Will it require major change to the program? __ Raymond On Mon, Oct 29, 2012 at 4:10 AM, Pierre Joye pierre@gmail.com wrote: hi, No, we won't implement that as it is already available by default on windows. check the AutoBackupLogFiles option. For people not using windows log system but classic files, there are plenty of tools to do it as well. Cheers, On Sat, Oct 27, 2012 at 11:53 AM, Kris Craig kris.cr...@gmail.com wrote: On Sat, Oct 27, 2012 at 2:17 AM, Mario Brandt jbl...@gmail.com wrote: Hi, On Thu, Oct 25, 2012 at 9:59 PM, Antony Dovgal t...@daylessday.org wrote: Just use logrotate for that. On Windows there is no logrotate by defautl, so that would be a nice feature ;) Cheers Mario -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I agree. This would definitely be a nice feature to have, at least for the Windows build. --Kris -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is GD being actively maintained?
The good news is that gd is pretty moribund, there isn't a lot to maintain. But things do come up. libgd.org has been displaying the same oops crap something happened notice for... three years? At least? If there is no momentum to fix that, as the original developer of gd I would be willing to restore the classic gd documentation there and continue linking to the bitbucket project. On Thu, Sep 6, 2012 at 9:15 AM, Jannik Zschiesche he...@apfelbox.net wrote: Am Donnerstag, 6. September 2012 um 15:05 schrieb Alexey Shein: Hi, Rasmus, Just wanted to note that I've tested your script from http://fontjazz.com/metrics/test.php and couldn't reproduce the bug. I'm on the Ubuntu 12.04 with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch Have you tried upgrading your FreeType library and recompiling latest stable PHP with it? Good luck. P.S. I'm not a GD developer. Hi Alexey, I just tested it on PHP 5.4.4 on OSX and I can confirm, that the issue is still present. (used font: Open Sans Regular/Bold/Italic, screenshots: http://min.us/mM2c5yyBU ) Cheers Jannik Zschiesche -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Integrate PECL into PHP
There is already a safe and sensible way to do this in a shared hosting environment: the host installs pecl packages that everyone gets, and only after verifying that they don't reduce the security of the shared environment. Or, yes, just get a vps! Really, it's not expensive anymore (: On Sat, Aug 4, 2012 at 5:36 PM, Lester Caine les...@lsces.co.uk wrote: Yahav Gindi Bar wrote: Shared hosting is cheap for a reason, and trying to cheat shared hosters by changing PHP both wrong and pointless. My wish is not to cheat using PHP but to give the shared hosting users somehow the ability to enjoy from PECL packages without being restricted to their providers. Got your point - maybe it's not possible and I'm just trying to keep the cake and eat it... even this said, if somebody got an implementation idea or any other way (except from requesting it from the provider) I'd love to hear it:) On most distributions many of the core facilities are simply a group of enabled modules. All that is required to use PECL as well is for those module to be packaged and available in the list of enable-able modules. I don't think that anything should be done to take that control away from the ISP's that are providing the service. -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 6.0 And Moving Forward
For a new version to be successful from a marketing perspective, there has to be such a thing as good old code. Just as there are PHP 4 apps that are basically sound and maintainable code and require only a few reasonable changes to run well in PHP 5, that needs to be true for the transition to 5 to 6. Otherwise it just won't be accepted as PHP by most people. If I have to start from scratch, I guess I'll just use Ruby would be a very reasonable response (: I do like the idea of pseudo-objects with methods as a way to create much cleaner APIs for strings and arrays, but the legacy APIs need to stick around. On Tue, Jul 17, 2012 at 7:16 PM, David Muir davidkm...@gmail.com wrote: Took the words from my mouth. Removing legacy support is a terrible idea for PHP6. It makes it impossible to write forwards compatible code that currently runs in PHP5. Even having it optional is a bad idea IMO since it will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), some will be able to run PHP5+ but will still be marketed as PHP6. Makes it that much harder to know if your code will run on a client's server. David On 18/07/12 00:04, Anthony Ferrara wrote: I dislike this idea from the ground up. While I think having a legacy implementation is definitely worth while, it needs to be in core. So PHP6 would introduce the new syntax, and include the legacy functionality in as close to 100% backwards compatible way as possible. From there, we'd only remove the legacy functionality from core in 7 (which could be 4 or 5 years out). We don't want to be in the same situation with 6 that python was in with 3, and perl was in 5. We want to encourage adoption. Having a PECL extension needed for adoption is not going to fly too well. But if we can add the new functionality and give people an easy migration path, adoption will be easier. It still may take years, but it will at least be fairly smooth as the majority of existing code will still work. Of course some BC breaks may be necessary (a-la what happened with PHP5), but they should be fairly localized and pretty easy to handle... And they should be justified (breaking BC for the sake of it, as with these legacy functions, would be a mistake)... My $0.02 at least. Anthony On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds ajf...@googlemail.comwrote: This is an excellent idea. Full BC yet without legacy cruft. Old code runs on legacy support extensions, new code doesn't need it. On Jul 17, 2012 1:51 PM, Leigh lei...@gmail.com wrote: Basically, the current function library is moved to the legacy namespace. The default setting is import the functions of the legacy namespace into the root namespace for BC. But with that setting turned off all the existing functions go away to be replaced with a designed API, instead of a grown one, correcting the mistakes that have accumulated over the years. Is there any reason why this cannot / should not be implemented as a PHP 5 compatibility extension? I think those who never want to use it (PHP 6 purists) shouldn't have to have their binaries bloated by legacy code. It would also mean that the legacy implementation can be developed away from the new core, and not have any (negative) influence on it. -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Hmm, but the stat=0 optimization is a major one; a cache that didn't offer it would be significantly slower in production for those who know what they're doing, yes? (I haven't actually tried the stat=0 trick myself yet and don't have performance numbers on its impact. I really ought to though, since hitting an API URL that clears the APC cache as part of deployment should be pretty easy.) On Wed, Jul 4, 2012 at 5:55 AM, Pierre Joye pierre@gmail.com wrote: hi Rasmus, On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/03/2012 08:17 AM, Pierre Joye wrote: I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. There are really just two big features in APC. The opcode caching and the user-cache that sits on top of the same shared memory segment used by the opcode cache. Right, I wold like to split them tho'. To have two independent memory for opcodes and user cache. Everything else are just little tweaks that amount to very little code. Maintenance complexity is not necessary related to the amount of code but the amount of cases to test. These cases also make very hard for our users to understand APC and how it behaves (the stat=0 being the easiest one to understand but causing most issues, for example). That's where eAccelerator or xCache do way better, if it works, it simply works, no magic option or other confusing (for the users) options. The biggest cleanup we would get moving it to core would be the ability to drop all the #ifdef checks for the different engine versions since we would obviously only need to support the current one. We will still have to support current supported versions via PECL. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Heh... passing a little judgment there on the design of frameworks, ORMs, etc. are we? On Wed, Jul 4, 2012 at 10:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/04/2012 07:37 AM, Tom Boutell wrote: Hmm, but the stat=0 optimization is a major one; a cache that didn't offer it would be significantly slower in production for those who know what they're doing, yes? Depends on your code. For people who write code that needs to include hundreds, or even thousands of files per request, yes, stat=0 is a big feature. For saner code it is much less important. -Rasmus -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
This one: *** glibc detected *** /usr/local/bin/php-cgi: double free or corruption (out): 0x7f9d6ce2c080 *** === Backtrace: = /lib/libc.so.6(+0x77806)[0x7f9d679be806] /lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3] /usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d] /usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393] /usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460] Is pretty nasty and we're getting it on lots of servers. #61238 says it's a known and fixed issue, but we still have it with a fresh build of PHP 5.4.4 and apc installed immediately thereafter via pecl. Is this fix actually released yet? Thanks. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: On Tue, Jul 3, 2012 at 10:20 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/03/2012 07:13 AM, Tom Boutell wrote: This one: *** glibc detected *** /usr/local/bin/php-cgi: double free or corruption (out): 0x7f9d6ce2c080 *** === Backtrace: = /lib/libc.so.6(+0x77806)[0x7f9d679be806] /lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3] /usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d] /usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393] /usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460] Is pretty nasty and we're getting it on lots of servers. #61238 says it's a known and fixed issue, but we still have it with a fresh build of PHP 5.4.4 and apc installed immediately thereafter via pecl. Is this fix actually released yet? Like I said in the bug report, install APC from SVN. We have a few more things to fix before we are ready for an APC release. Unfortunately there are a lot fewer people working on APC than other parts of PHP. It is extremely difficult and not very sexy work. And with that enticing description, if anyone reading this would like to pitch in and help fix the remaining small PHP 5.4 edge cases in APC, it would be much appreciated. -Rasmus -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
The ability to store your own data in the APC cache is a feature that does get used a lot in the Symfony framework world because of the availability of the sfAPCCache and whatever its Symfony 2 equivalent is. It's popular with folks who haven't felt the need to set up Redis or some other external cache yet. I'm not sure whether this is something you consider a legacy feature. On Tue, Jul 3, 2012 at 11:17 AM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: There are alternative opcode cachers besides APC. For example xcache, for me, just works when APC is still catching up. I remember someone writing about APC that it is overly compex internally and due to that hard to keep up with the changes in the PHP, maybe that is not the case now. It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Cheers, 2012/7/3 Tom Boutell t...@punkave.com Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Resume keyword
Saying that the exception handler shouldn't have called resume in
the case where the exception was originally thrown in a deeper stack
frame sounds good until you consider that this requires exception
handlers to know whether the code preceding them has been refactored
or not, which makes it tough to separate concerns and invites
situations where it is harder than ever to figure out the side effects
of what you're doing. Exception handlers ought to be able to look at
the exception object alone in order to figure out what to do.
On Thu, Jun 21, 2012 at 8:11 AM, Michael Morris dmgx.mich...@gmail.com wrote:
On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs
krebs@googlemail.com wrote:
2012/6/20 Michael Morris dmgx.mich...@gmail.com
[/snip]
An example for additional clarity.
set_exception_handler(function ($e) {
echo $e-getMessage();
// Don't know if this is correct - but should be able to illustrate here
if ($e-getCode() == E_NOTICE E_STRICT) {
resume null;
}
echo 'Dying now'; exit;
});
throw new Exception('A test', E_NOTICE);
echo We didn't die;
The code above when run would echo A test. We didn't die.;
Whats about
$user = $this-getUser(); // Throws exception
echo $user-getName();
Now the second one will fail too, but in reality it shouldn't even get
executed...
Regards,
Sebastian
Then the error handler shouldn't have called resume. The error
handler should only call the keyword if its safe to do so. And now
that I think about it, not having the ability to return anything would
be for the best since it would keep the usefulness of this to a
minimum and avoid magic headaches.
Cause the last thing we need is for people to start using the
exception handling mechanism as additional control structure tree.
What about what I'd mentioned before that this would allow? With this
in place the existing PHP Errors could all be converted to Exceptions.
The default exception handler would resume after catching any low
level exceptions (E_NOTICE, E_WARNING, etc) but a custom one can be
free to do whatever.
Unifying the mechanisms also would allow for exceptions for other
fatal events. This would be highly useful.
try {
require( 'path/to/file.php' );
} catch ( PARSE_EXCEPTION $e ) {
// some logging then pretty death
}
Most of the time you'd never want to resume after such an
exception Most of the time.
In any event resume would allow PHP to get back to having only one
exception mechanism instead of two since the behavior of errors could
be emulated under exceptions. That is the principle boon of resume.
Does that balance the two drawbacks
1) It's a new keyword, so BC breaks occur with code that used it as a
function name.
2) The spaghetti possibilities increase.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
Can you really use setjmp and longjmp in that way safely? I thought it was only safe to longjmp back, not forward - you can use them to fake exception support but that's it because you'll smash the stack otherwise. Something like that... OK, I'm thinking of this: Similarly, C99 does not require that longjmp preserve the current stack frame. This means that jumping into a function which was exited via a call to longjmp is undefined.[6] However, most implementations of longjmp leave the stack frame intact, allowing setjmp and longjmp to be used to jump back-and-forth between two or more functions—a feature exploited for multitasking. It does not sound like something that can be done in portable C. On Mon, Jun 11, 2012 at 4:13 PM, Anatoliy Belsky a...@php.net wrote: Hi, it'd be really cool if the implementation would do the real context switch in c, which would be the true basis for spl_coroutine. The current implementation seems not to do that. Context switch in c would be comparable with threads. In fact coroutines would be a comensation for lacking threads functionality in php, as they are already implemented on most popular platforms. However, it would require some platform specific libs (fibers on windows, setjmp and longjmp on unix(like)). Coroutines in c are per se thread safe, so implementing them once would not hurt both ts and nts. Additionally, in some cases coroutines can even have advantages over the usual preemptive threads. Regards Anatoliy Am Mi, 6.06.2012, 04:42 schrieb Laruence: On Wed, Jun 6, 2012 at 10:27 AM, Laruence larue...@php.net wrote: On Wed, Jun 6, 2012 at 10:15 AM, Laruence larue...@php.net wrote: Hi Nikita: the most important part to me is how did you implemented `yield` keyword, is there a whole patch file I can look into? Nervermind, I will check the branch out later thanks After a quick look, I think the main idea should goes to two parts: 1. implement yield (Zend) 2. implement spl_generators but not generator class (Spl) then we can implement spl_coroutine later base on this. what do you think? thanks what will happen if you use a `yield` in a normal function? actually, I tried to implemented coroutine, but since I could not find a way to make zend_execute interruptable, then I didn't make it. so, I am really interesting of this tech-specific :) thanks On Wed, Jun 6, 2012 at 1:35 AM, Nikita Popov nikita@googlemail.com wrote: Hi internals! In the last few days I've created a proof of concept implementation for generators in PHP. It's not yet complete, but the basic functionality is there: https://github.com/nikic/php-src/tree/addGeneratorsSupport The implementation is outlined in the RFC-stub here: https://wiki.php.net/rfc/generators Before going any further I'd like to get some comments about what you think of adding generator support to PHP. If you don't know what generators are you should have a look at the Introduction section in the above RFC or in the Python documentation at http://wiki.python.org/moin/Generators. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php interpreter
I've seen this statement before about the impact of caching the actual
compilation (or mere tokenization?) to bytecode being very small
compared to the impact of avoiding disk access. I am curious if there
are any measurements breaking this down. Read-only access to code in
files already buffered by the OS (not files read for the first time)
ought to be very fast.
On Tue, May 22, 2012 at 11:00 AM, Richard Lynch c...@l-i-e.com wrote:
On Wed, May 9, 2012 5:05 pm, Xin Tong wrote:
I am new to php runtime. i am doing some research on runtime
interpreter. can anyone please tell me where the interpreter of the
php runtime is ? which file ? and does the php runtime has a JIT
compiler ?
I believe the interpreter is built out of bison/yacc files, so you
could start with those to find out where they put it.
The php runtime is a JIT parser/compiler to a bytecode, which is then
run by the Zend Engine (see above).
Actually, that last statement might imply the the zend directory would
also be a good place to look.
Finally, it should be noted that APC and other caching mechanisms save
a great deal of time by not hitting the disk to load the script, but
keeping it in RAM, if possible.
As gravy on top of that, the bytecode is saved in cache instead of
source, so it is not a JIT if one of those caches is in use.
Psuedo code to describe the difference the APC (or other cache) makes:
//save hitting the hard disk
if ( $source_code = in_cache($path)){
}
else{
//super-duper slow!!!
$source_code = file_get_contents($path);
}
$bytecode = zend_parse($source_code);
zend_execute($bytecode);
//save hitting the hard disk
//and a small bonus, cache the bytecode, not source:
if ($bytecode = in_cache($path)){
//do nothing
}
else{
$source_code = file_get_contents($path);
$bytecode = zend_parse($source_code);
}
zend_execute($bytecode);
The savings from parsing is chump change compared to disk I/O.
It's also trivial chump change to implement.
Ever ounce counts :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php interpreter
(I'm not questioning that APC makes an enormous difference. That's
painfully obvious from 100 miles away on our servers (: )
On Thu, May 24, 2012 at 11:23 AM, Tom Boutell t...@punkave.com wrote:
I've seen this statement before about the impact of caching the actual
compilation (or mere tokenization?) to bytecode being very small
compared to the impact of avoiding disk access. I am curious if there
are any measurements breaking this down. Read-only access to code in
files already buffered by the OS (not files read for the first time)
ought to be very fast.
On Tue, May 22, 2012 at 11:00 AM, Richard Lynch c...@l-i-e.com wrote:
On Wed, May 9, 2012 5:05 pm, Xin Tong wrote:
I am new to php runtime. i am doing some research on runtime
interpreter. can anyone please tell me where the interpreter of the
php runtime is ? which file ? and does the php runtime has a JIT
compiler ?
I believe the interpreter is built out of bison/yacc files, so you
could start with those to find out where they put it.
The php runtime is a JIT parser/compiler to a bytecode, which is then
run by the Zend Engine (see above).
Actually, that last statement might imply the the zend directory would
also be a good place to look.
Finally, it should be noted that APC and other caching mechanisms save
a great deal of time by not hitting the disk to load the script, but
keeping it in RAM, if possible.
As gravy on top of that, the bytecode is saved in cache instead of
source, so it is not a JIT if one of those caches is in use.
Psuedo code to describe the difference the APC (or other cache) makes:
//save hitting the hard disk
if ( $source_code = in_cache($path)){
}
else{
//super-duper slow!!!
$source_code = file_get_contents($path);
}
$bytecode = zend_parse($source_code);
zend_execute($bytecode);
//save hitting the hard disk
//and a small bonus, cache the bytecode, not source:
if ($bytecode = in_cache($path)){
//do nothing
}
else{
$source_code = file_get_contents($path);
$bytecode = zend_parse($source_code);
}
zend_execute($bytecode);
The savings from parsing is chump change compared to disk I/O.
It's also trivial chump change to implement.
Ever ounce counts :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Actually, I just updated Rasmus' demo program to use assocative arrays instead of objects. In PHP 5.4.x, the associative array version uses more memory than the object oriented version. That's because PHP 5.4.x is using a flat array for predeclared properties, as was mentioned earlier by Gustavo. Associative arrays: 524288 bytes Objects: 262144 bytes The object-oriented version is also faster, by about 20%. Interestingly these results don't change much if I make the property names/keys much shorter. Probably there's a minimum allocation of 64 bytes for these or something. It would appear there is no longer a penalty simply for using many objects vs. many associative arrays in PHP 5.4. The opposite, in fact. I'm sure arrays didn't get slower, but objects now take advantage of some optimizations that become possible when properties are predeclared. However this doesn't mean that calling lots of setters will necessarily be as fast as direct property access... oh what the heck, let's test that too: Calling dead-simple setters for the four properties rather than setting them directly slows down the OOP version to the point where it runs at just about the same speed as the associative array version. That's not terrible. Direct property access is still fastest (after all that's what the setters do after they pay the overhead of the function call). On Mon, May 21, 2012 at 9:23 PM, Richard Lynch c...@l-i-e.com wrote: No offense intended, but if you've got so many OOP objects flying around that they are sucking down that much memory... You probably need to refactor your code and just don't do that Just my opinion. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC benchmark
You might be better off testing a nontrivial case like a framework based web application's homepage with and without APC turned on for 100 fetches. That's where APC really shines. On Tue, May 22, 2012 at 11:18 AM, Mohammad Saleh msaleh...@hotmail.com wrote: All, I was looking for a standard benchmark script that I could run with and without apc caching to see the general gains. Is there something that is used by the internals team for such tests? If not, are there any recommendations? Thanks, Mohammad -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC benchmark
Including Wordpress in your test does sound fairly realistic actually, but it's a good sign that something else becomes the bottleneck with APC enabled (: On Tue, May 22, 2012 at 12:46 PM, Mohammad Saleh msaleh...@hotmail.com wrote: Thank you for the feedback Tom. I actually created a simulated test with jmeter and wordpress and was testing that with and without apc (simulation of a set of authors and readers). Once I turned on APC, I realized my db server became a bottleneck and I was not able to test the max throughput. Your scenario removes the db and focuses strictly on the cached pages, so I will give that a try. Thanks and if there are any other suggestions, please do let me know! - Mohammad Date: Tue, 22 May 2012 11:38:56 -0400 From: t...@punkave.com To: internals@lists.php.net Subject: Re: [PHP-DEV] APC benchmark You might be better off testing a nontrivial case like a framework based web application's homepage with and without APC turned on for 100 fetches. That's where APC really shines. On Tue, May 22, 2012 at 11:18 AM, Mohammad Saleh msaleh...@hotmail.com wrote: All, I was looking for a standard benchmark script that I could run with and without apc caching to see the general gains. Is there something that is used by the internals team for such tests? If not, are there any recommendations? Thanks, Mohammad -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Yeah, dynamic properties get used by default every time you json_decode something, to take a random example. String folding could be used, but that would require a hashtable lookup and would probably be slower than allocation (at least until you started to swap). Worth testing maybe. Or... when you instantiate an object, it still looks like a hash, but declared property names are initialized to point at shared strings. Dynamic property names aren't. When the object is reclaimed, the declared properties are removed first to prevent double deallocations, and then the dynamic properties are destroyed. I'm suggesting a lot of work here I'm sure, but this latter idea seems like it might yield a large memory usage improvement. On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! How come it's necessary to store the property-names of every property in every object? For properties that have been defined in classes, why can't they be stored in a more efficient manner? (using lookup tables) No because you can add and remove properties freely at runtime. I know the nature of PHP is dynamic, and I know that dynamic properties would have to be stored in a key/value form internally... but if you look at modern PHP software, dynamic properties is actually something very few people use. This is not true. -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Thanks for clarifying that. Sounds like a huge win. On Mon, May 21, 2012 at 3:13 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk wrote: I just realized something that never occurred to me before - every property is actually stored as a hash. This test-script will demonstrate: [snip] The test-script contains no information about the version of PHP you're using. Starting with PHP 5.4, the properties hash table is only created if you're storing dynamic properties (i.e. assigning undeclared properties) or if it otherwise requested. Otherwise, they're stored in an array. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
I ran this script on 5.3.13, and it reported: 786432 bytes used On 5.4.3, it reported: 262144 bytes used That is definitely a significant improvement. Objects are still a lot bigger than their contents. I don't expect they would ever shrink to the size of their contents exactly or even all that close of course. On Mon, May 21, 2012 at 3:25 PM, Tom Boutell t...@punkave.com wrote: Thanks for clarifying that. Sounds like a huge win. On Mon, May 21, 2012 at 3:13 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk wrote: I just realized something that never occurred to me before - every property is actually stored as a hash. This test-script will demonstrate: [snip] The test-script contains no information about the version of PHP you're using. Starting with PHP 5.4, the properties hash table is only created if you're storing dynamic properties (i.e. assigning undeclared properties) or if it otherwise requested. Otherwise, they're stored in an array. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory usage ouchy
Rasmus, isn't your concern about the impact of dynamic property support on developers who don't actually use it a nonissue in 5.4, where properties that aren't dynamic are stored as a flat array? On Mon, May 21, 2012 at 4:52 PM, Rasmus Schultz ras...@mindplay.dk wrote: Adding/removing properties at runtime is great if you want obscure, unmaintainable code and don't think an IDE is useful. So to make my previous statement more precise, dynamic properties are not widely used in respectable modern codebases, and is generally something a reputable developer would frown upon. Yes, some codebases (e.g. Drupal) rely on this extensively, but modern frameworks generally do not - in fact, they often take measures to ensure that exceptions are thrown if you try to access a property that has not been formally defined. For that matter, most ORMs (a typical example of where dynamic properties would come in handy) don't rely on dynamic properties either - they rely on __get() and __set() and store the actual values in a single property, as an array. So even for highly dynamic components in modern frameworks, this is not a feature that is often used. Drupal-development aside, and perhaps some XOOPS-development back in the dark ages, I can't actually recall when I've used dynamic properties. I suddenly realize why certain heavily-used classes in the Yii framework have obscure property-names like $_m and $_p ... they're trying to save memory. Not really logical that you should have to compromise legible code in favor of saving memory. Makes me wonder if this issue could be addressed, killing two birds with one stone. Since the dynamic aspect is an inconvenience to many developers, and since it causes memory-overhead whether they make use of this feature or not, how about introducing a non-dynamic alternative base-class that actually throws if you access properties that have not been defined? This wouldn't change the way PHP objects work by default, but would lighten the memory-overhead in a lot of modern frameworks, and possibly speed up property-access too, since you can have a flat look-up table for class-properties; and could eliminate the need for an object or component base-class in frameworks... On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! How come it's necessary to store the property-names of every property in every object? For properties that have been defined in classes, why can't they be stored in a more efficient manner? (using lookup tables) No because you can add and remove properties freely at runtime. I know the nature of PHP is dynamic, and I know that dynamic properties would have to be stored in a key/value form internally... but if you look at modern PHP software, dynamic properties is actually something very few people use. This is not true. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
This whole business of bending over backwards to prevent injection of php when apache is misconfigured just encourages apache misconfiguration IMHO. Smart people are protecting you, you don't have to do these things right, don't worry about it! Sent from my iPhone On May 5, 2012, at 1:50 PM, Richard Lynch c...@l-i-e.com wrote: On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote: On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. yeah, and injecting php code through the jpeg comments isn't new also, see http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/ but I bet I could find even older posts discussing the topic. so imo the correct remedy for this situation is to prevent your uploaded files to be executed at the first place, instead of trying to write an error-prone method to detect malicious content inside your uploaded media files. getImageSize is not better than file Info... If the whole thing parses as an image with imagecreatefromjpeg() I should think that's a bit tougher to create a hack that works. Then one can strip off the exif info with the comments, I believe. And, yes, ideally one would keep images in a totally separate directory not even in the webtree... Which I do, but some folks can bear the cost of passing the image through PHP. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- 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] [RFC] Pure PHP Scripts (Updated)
* The RFC starts off immediately talking about file extensions, but the actual implementation proposed doesn't rely on file extensions or suggest any enforcement of them. That disparity should be addressed for clarity. * The RFC quotes an entire discussion with a lot of harsh language about coding practices that are currently considered standard in most MVC frameworks, including the original message you were responding to (which happened to be mine). I am not sure you intended to leave all that in. In general that discussion contradicts the work you've done elsewhere in the RFC to propose both .phpp and .phpf. On Tue, Apr 24, 2012 at 3:52 PM, Kris Craig kris.cr...@gmail.com wrote: Hi all, I finally found some time today to update the RFC based on discussions here. Please have a look and let me know if I missed anything or if there's anything else that needs clarifying: https://wiki.php.net/rfc/phpp I also want to know if this is sufficient to satisfy some of the concerns that have been raised about being able to implement this into existing frameworks that use a more tangled architecture. Thanks! =) --Kris -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)
That's a good point, it should say the PHP tokenizer, or something to that effect (folks who spend more time with the internals could say better what to call it). The major difference from his previous version of the RFC is his addition of the .phpf format, which would allow including a .php file with ?php and ? in it from a .phpf file, but would not allow or need any usage of ?php and ? within the .phpf file itself. On Tue, Apr 24, 2012 at 4:14 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: As far as I read there is no difference from the previous RFC - it says essentially the same. The ?php tag, contained within one of these files, tells the webserver to, in essence, switch to PHP mode and start parsing the data as PHP code. When the ? tag is reached, the webserver switches back and resumes parsing it as HTML. If no tags are given, the webserver will parse the file data as HTML code until a ?php tag is reached. I'm I the only one who thinks that this is just plain wrong? I know for a fact that there is no PHP mode on the WEB server level. I think I understand what it tries to say, but I totally disagree with what is written and don't want to guess anything. 24 апреля 2012 г. 22:52 пользователь Kris Craig kris.cr...@gmail.comнаписал: Hi all, I finally found some time today to update the RFC based on discussions here. Please have a look and let me know if I missed anything or if there's anything else that needs clarifying: https://wiki.php.net/rfc/phpp I also want to know if this is sufficient to satisfy some of the concerns that have been raised about being able to implement this into existing frameworks that use a more tangled architecture. Thanks! =) --Kris -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)
Please review the section titled Inclusion of Mixed Code, which contains the quoted conversation I referred to, with commentary about bad, lazy architecture that is currently standard in numerous frameworks. I understand that you feel that in future such frameworks will make a different set of choices, but it still doesn't make sense to import that old thread of argument into your RFC directly. I think you mean to present the diagram only, with a more dispassionate explanation of its purpose. On Tue, Apr 24, 2012 at 7:27 PM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@punkave.com wrote: * The RFC starts off immediately talking about file extensions, but the actual implementation proposed doesn't rely on file extensions or suggest any enforcement of them. That disparity should be addressed for clarity. Did you read the whole RFC? Please refer to the Naming Conventions section. It addresses this explicitly. Are you saying that section wasn't sufficiently clear or did you just miss it? I think what he means is that the abstract section should be, well, abstract. Currently it appears more detailed than it should be by referring to file extensions on the let go. I would phrase that section in a way that doesn't rely on another section to explain the used terminology. Also, references such as .phpp are used throughout the document to indicate a particular type of source file rather than an actual file extension. As such I would recommend moving your terminology section to right underneath abstract. This would improve the readability. Hmm I see your point. Ok I'll update that langauge next time I can find a spare moment. So aside from that, what are your thoughts? In addition to feedback on the wording itself, I'd also be interested in hearing your thoughts on the actual amended proposal itself. Does the new script type alleviate your main concerns about frameworks (keeping in mind that a compromise is a solution that neither party likes but both parties can live with)? What do you think about the require/include syntax suggestions? Should it be comma-delinated or use as instead? Etc. Thanks! --Kris -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Complete case-sensitivity in PHP
Yup - a one time transition would be preferable to that. On Fri, Apr 20, 2012 at 9:13 AM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2012-04-20, C.Koy can5...@gmail.com wrote: This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) which is a decade old. As the recent comments on that page indicate, there's not a deterministic way to resolve this issue, apart from eliminating tolower() calls for function/class names during lookup. Hence totally case-sensitive PHP. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? It's not just about changes to the engine. If you introduce a runtime option that switches behavior, you then get a portability problem -- code runs fine in one context, but not the other. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Some Stats
The author of an RFC does need to respond to concerns raised (although possibly not the same concerns over and over). On Tue, Apr 17, 2012 at 3:46 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 04/17/2012 11:41 AM, Kris Craig wrote: On Mon, Apr 16, 2012 at 11:57 PM, Rasmus Lerdorf ras...@lerdorf.com mailto:ras...@lerdorf.com wrote: Number of posts to internals since Jan.1,2012 (top 15): [kris.cr...@gmail.com mailto:kris.cr...@gmail.com] = 249 Wooot! What's my prize? ;P Now I just need to start getting some commits in there Kris, this was actually the point of that email. You are extremely busy on this list and while I appreciate the enthusiasm, it would be good if you could try to refrain from commenting on every single thread multiple times every day. Let it sit for a while, see what everyone has to say and write a single message with your thoughts. This list is mainly for the people working on the code. Many of us are simply deleting entire threads unread at this point which isn't a healthy habit to get into. One idea for everyone on the list is a kind of self-imposed list posting quota. For every commit, bug comment, doc contribution, infrastructure contribution you make you get a post to the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
We could vote on whether we like the idea in principle, with the condition that the final proposal pass separately as a fully detailed rfc. That way you are telling the authors of these rfcs whether to keep trying and in what direction, but you are not forced to accept the end product. I would welcome such a vote just to end fruitless debate on the three points I mentioned. Sent from my iPhone On Apr 16, 2012, at 3:46 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Apr 16, 2012 at 3:39 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, It would be better to vote - PHP will have script only (tag less) code or not then - How it will be implemented Regards, That idea was raised a few times in the past, but Stas and others expressed, they (and maybe most people) can only vote for something, if the implementation details are tailored out (a patch is nice to have, but not necessary), otherwise you can't measure whether that change is feasible at all. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
These tools already strip ?php tags, they would need minimal changes to support rolling in a .phpp file unmodified. Unless I am missing something? Sent from my iPhone On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: I posted the bellow text in other thread, but i should have it post here, so i'm reposting it to this thread. Well, it's time for me to remind about the techique many use (and some frameworks provide it out of the box) - the application file concatination to speed up file loading. Yii framework provides a Yiilite.php file for this, that includes mostly used core classes in one big file.that loads much faster and is used for production. Any other framework has user extentions or other type of solutions for this to speed up the application, and it makes really big difference. So there is a good question - how the hell in a MVC framework would i combine my models, controllers, components and other stuff that will definetly be as in .php so in .pphp. And not every file will be cached like that - some will remain as distinct files even in production. The further discussion goes the more questions there is and less answers there are. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Oh I see. Yes, this is one of the reasons I don't like the pure can't include non-pure idea. Another reason: you can't write generic algorithms. PHP 5.4 has much improved support for anonymous functions, so we should see an increase in libraries that take a few functions as parameters and carry out an operation via those functions. But what if one of those functions requires something from a .php file? Whoops, I guess it's not a generic sorting algorithm library I just released, it's a generic sorting as long as none of your functions touch a .php file algorithm library. And good luck figuring this out when it happens. Kris has pointed out that you could still load a .php file via a function that was defined earlier in a .php file that later includes .phpp. But this just means that, like my RFC, his RFC contains a compromise about strictness. It's just that his compromise is more confusing and less likely to be understood before the user gets frustrated and declares the whole thing not worth messing with. I think .phpp files don't contain ?php and ? but can require and include files that do is a much clearer compromise, one that will get us what we want (an ever increasing percentage of .phpp files) without making enemies and generating opposition along the way to that better place. On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: 16 апреля 2012 г. 16:09 пользователь Tom Boutell t...@punkave.com написал: These tools already strip ?php tags, they would need minimal changes to support rolling in a .phpp file unmodified. Unless I am missing something? Sent from my iPhone On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: I posted the bellow text in other thread, but i should have it post here, so i'm reposting it to this thread. Well, it's time for me to remind about the techique many use (and some frameworks provide it out of the box) - the application file concatination to speed up file loading. Yii framework provides a Yiilite.php file for this, that includes mostly used core classes in one big file.that loads much faster and is used for production. Any other framework has user extentions or other type of solutions for this to speed up the application, and it makes really big difference. So there is a good question - how the hell in a MVC framework would i combine my models, controllers, components and other stuff that will definetly be as in .php so in .pphp. And not every file will be cached like that - some will remain as distinct files even in production. The further discussion goes the more questions there is and less answers there are. Yes they obviously do, but that's not what I'm concerned about. What I'm concerned is that code from .php and .pphp files get's mixed in together - template engine related stuff is used as much, as do controllers, session handling classes and bunch of other stuff that by definition is .pphp stuff, but the template stuff is .php and it includes templates. So basically everything just has to fall back to the embedded PHP mode to work and we have no gain from the proposal what so ever - it just becomes useless. That's not counting other issues that people and I have been voicing and to be honest, I never saw a reply to any of it. Maybe there is a reply to all those questions, but they are under wall of text that usually goes in reply - that just discourages to read it at all. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Also, Kris's proposal requires that an additional flag be tracked all the way down through the stack of requires and includes from the point where pure mode is first encountered, remembering that we're in pure mode. Note that this flag cannot be a global variable because .php files that were loaded before this .phpp file are still permitted to load things, including when acting as autoloaders on behalf of .phpp code... my head hurts. This cannot be the cleanest way to solve the problem. 2012/4/16 Tom Boutell t...@punkave.com: Oh I see. Yes, this is one of the reasons I don't like the pure can't include non-pure idea. Another reason: you can't write generic algorithms. PHP 5.4 has much improved support for anonymous functions, so we should see an increase in libraries that take a few functions as parameters and carry out an operation via those functions. But what if one of those functions requires something from a .php file? Whoops, I guess it's not a generic sorting algorithm library I just released, it's a generic sorting as long as none of your functions touch a .php file algorithm library. And good luck figuring this out when it happens. Kris has pointed out that you could still load a .php file via a function that was defined earlier in a .php file that later includes .phpp. But this just means that, like my RFC, his RFC contains a compromise about strictness. It's just that his compromise is more confusing and less likely to be understood before the user gets frustrated and declares the whole thing not worth messing with. I think .phpp files don't contain ?php and ? but can require and include files that do is a much clearer compromise, one that will get us what we want (an ever increasing percentage of .phpp files) without making enemies and generating opposition along the way to that better place. On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: 16 апреля 2012 г. 16:09 пользователь Tom Boutell t...@punkave.com написал: These tools already strip ?php tags, they would need minimal changes to support rolling in a .phpp file unmodified. Unless I am missing something? Sent from my iPhone On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: I posted the bellow text in other thread, but i should have it post here, so i'm reposting it to this thread. Well, it's time for me to remind about the techique many use (and some frameworks provide it out of the box) - the application file concatination to speed up file loading. Yii framework provides a Yiilite.php file for this, that includes mostly used core classes in one big file.that loads much faster and is used for production. Any other framework has user extentions or other type of solutions for this to speed up the application, and it makes really big difference. So there is a good question - how the hell in a MVC framework would i combine my models, controllers, components and other stuff that will definetly be as in .php so in .pphp. And not every file will be cached like that - some will remain as distinct files even in production. The further discussion goes the more questions there is and less answers there are. Yes they obviously do, but that's not what I'm concerned about. What I'm concerned is that code from .php and .pphp files get's mixed in together - template engine related stuff is used as much, as do controllers, session handling classes and bunch of other stuff that by definition is .pphp stuff, but the template stuff is .php and it includes templates. So basically everything just has to fall back to the embedded PHP mode to work and we have no gain from the proposal what so ever - it just becomes useless. That's not counting other issues that people and I have been voicing and to be honest, I never saw a reply to any of it. Maybe there is a reply to all those questions, but they are under wall of text that usually goes in reply - that just discourages to read it at all. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
For some this is sufficient, for others (like myself) getting rid of the initial ?php for pure files is a primary motivation. On Mon, Apr 16, 2012 at 9:38 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: 16 апреля 2012 г. 11:05 пользователь Kris Craig kris.cr...@gmail.comнаписал: Arvids, On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: What happened with the proposal/RFC for expanding include/require with additional optional second param to allow for developers to define in place if he want's a pure PHP file to be included or a template file with direct HTML output? I like that proposal and take it over any other, because it gives developer a choice. And if things do not go the right way and he ends up screwing up somewhere - he is able to fall back to the old mode just by modifying the include/require statement (and in a MVC framework with autoload usage that would be 1-2 places in the whole project). All that stuff with keywords, removing ?php tags and using special extensions require a continuous effort from the developers, additional support from the IDE/editors/other tools. Do we really need all that just to give people the ability to load their scripts as a pure PHP code? To my mind a modification to the include/require statements is all there is required to add that extra thing that Kris want's so badly and does not require to change your habbits, IDE templates, waiting for IDE/editors/WEB source code highlight libraries/source analyzers/etc to catch up with the change. There is also a question I just raised that is not yet answered that the keyword/extension thing can just break the valid performance tweak technique, that is used extensively in any project with big code base. That may very well be the method proposed in my RFC, too. I haven't made up my mind on that point as I'd like to cover the pros/cons a little more in depth (including the potential perf issue you just raised). A handler approach or something similar will still be necessary as well, since one key reason for my RFC was to make it so that these scripts could be executed directly via the webserver. But as for determining how PHP itself can identify a .phpp file, I think the three best options are: Create new tags, create new keywords, or create new parameters to existing keywords. I keep bouncing back and forth on which one I think is best, which tells me that I need to hear more debate on that. Thoughts? --Kris I would encourage you to take a deep look into modifying the include/require statements, because for all the issues popped out with .pphp and keywords they just don't exist with include/require. And there is no need to remove the ?php tags in source files - just make sure they start first thing in the file and there is no ? at the end and hey (for my case - my IDE removes all leading and trailing spaces on file save), your include 'file', PHP_SOURCE_ONLY; works fine, but including a template fails (as does an image with embedded ?php ? tags uploaded through a security hole) . It's clean (although some BC break would occur, but I think it's minor), simple and 100% voluntary. Any decently written 3rd party library will work without any modification (well, removing trailing ? is a matter of simple script if required, but I haven't seen people putting ? in the end for years). -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
I think the 'as' solution is smart. On Mon, Apr 16, 2012 at 3:54 PM, Kris Craig kris.cr...@gmail.com wrote: On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov nikita@googlemail.comwrote: On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer vch...@developersdesk.com wrote: On 4/16/2012 1:02 PM, Kris Craig wrote: On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmervch...@developersdesk.comwrote: More important include doesn't currently allow multiple parms: include foo.bar, 'baz'; Parse error: syntax error, unexpected ',' in bla.php on line xx Regarding include/require, I agree that any BC break would be extremely minimal. In the 10+ years I've been developing PHP, I don't think I've ever once seen somebody include multiple scripts on a single line (I wasn't even aware that such a thing was allowed). See above. It is not allowed now. I think there is a misunderstanding here. Inclusions with two arguments are currently not allowed, yes. The point is that adding such a second argument would make the grammar ambiguous. E.g, consider this: func(include 'foo', $someThing); Currently this is interpreted as the return value of 'foo' and the variable $someThing being passed to func. If you add a second argument it's unclear what this does. Is this a two-argument include? I.e. should it be interpreted as func((include 'foo', $someThing)); Or is this a one-argument include and should be interpreted as func((include 'foo'), $someThing); In my eyes such an ambiguity renders any proposal to add another argument to include completely unacceptable. The only option is to add a dedicated syntax for it like include 'foo' as $flags; Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hmm I like that idea. Anyone see any downsides to using as instead of comma delination? --Kris -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
This has been added in version 1.1.1 of the source_files_without_opening_tag RFC: https://wiki.php.net/rfc/source_files_without_opening_tag On Mon, Apr 16, 2012 at 5:25 PM, Tom Boutell t...@punkave.com wrote: I think the 'as' solution is smart. On Mon, Apr 16, 2012 at 3:54 PM, Kris Craig kris.cr...@gmail.com wrote: On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov nikita@googlemail.comwrote: On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer vch...@developersdesk.com wrote: On 4/16/2012 1:02 PM, Kris Craig wrote: On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmervch...@developersdesk.comwrote: More important include doesn't currently allow multiple parms: include foo.bar, 'baz'; Parse error: syntax error, unexpected ',' in bla.php on line xx Regarding include/require, I agree that any BC break would be extremely minimal. In the 10+ years I've been developing PHP, I don't think I've ever once seen somebody include multiple scripts on a single line (I wasn't even aware that such a thing was allowed). See above. It is not allowed now. I think there is a misunderstanding here. Inclusions with two arguments are currently not allowed, yes. The point is that adding such a second argument would make the grammar ambiguous. E.g, consider this: func(include 'foo', $someThing); Currently this is interpreted as the return value of 'foo' and the variable $someThing being passed to func. If you add a second argument it's unclear what this does. Is this a two-argument include? I.e. should it be interpreted as func((include 'foo', $someThing)); Or is this a one-argument include and should be interpreted as func((include 'foo'), $someThing); In my eyes such an ambiguity renders any proposal to add another argument to include completely unacceptable. The only option is to add a dedicated syntax for it like include 'foo' as $flags; Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hmm I like that idea. Anyone see any downsides to using as instead of comma delination? --Kris -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Kris, you have been talking recently about allowing for a mode that permits the inclusion of .php from .php... something (whatever we're calling this middle mode's recommended file extension). I think having three modes is overkill, but some people think having even two modes is overkill, so I'm prepared to live with having all three modes (traditional PHP, pure PHP that is allowed to include traditional PHP, and purest PHP that is not allowed to include traditional PHP). After all, I don't have to use purest mode if I choose not to do so - and I suspect most library authors won't because they want to write code that can include whatever the user wants it to. That's their choice and mine, and there's really no reason to deny you the option of purest mode. And one can make the argument that while, as you say, model code should never include a template, controller code (or classes in the view layer that manage templates) should invoke templates. That would give a better rationale for having all three types. However, your RFC still does not address allowing all three and currently includes very negative language about the middle option. A second issue is that your RFC calls for file extensions to be explicitly recognized by PHP itself, which is something many people have objected to because the file extension may be unavailable or irrelevant depending on the environment. That's why my RFC addresses the file extension issue as a strongly recommended convention, not a language feature, and provides keywords that can be used to implement that convention (and really ought to provide options for the various SAPIs as well, so entry points can be pure PHP if desired). I think it's probably time to write an updated version of your RFC so we can figure out if we're developing common ground here. 2012/4/16 Kris Craig kris.cr...@gmail.com: 2012/4/16 Tom Boutell t...@punkave.com Also, Kris's proposal requires that an additional flag be tracked all the way down through the stack of requires and includes from the point where pure mode is first encountered, remembering that we're in pure mode. Note that this flag cannot be a global variable because .php files that were loaded before this .phpp file are still permitted to load things, including when acting as autoloaders on behalf of .phpp code... my head hurts. This cannot be the cleanest way to solve the problem. 2012/4/16 Tom Boutell t...@punkave.com: Oh I see. Yes, this is one of the reasons I don't like the pure can't include non-pure idea. Another reason: you can't write generic algorithms. PHP 5.4 has much improved support for anonymous functions, so we should see an increase in libraries that take a few functions as parameters and carry out an operation via those functions. But what if one of those functions requires something from a .php file? Whoops, I guess it's not a generic sorting algorithm library I just released, it's a generic sorting as long as none of your functions touch a .php file algorithm library. And good luck figuring this out when it happens. Kris has pointed out that you could still load a .php file via a function that was defined earlier in a .php file that later includes .phpp. But this just means that, like my RFC, his RFC contains a compromise about strictness. It's just that his compromise is more confusing and less likely to be understood before the user gets frustrated and declares the whole thing not worth messing with. I think .phpp files don't contain ?php and ? but can require and include files that do is a much clearer compromise, one that will get us what we want (an ever increasing percentage of .phpp files) without making enemies and generating opposition along the way to that better place. On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks arvids.godj...@gmail.com wrote: 16 апреля 2012 г. 16:09 пользователь Tom Boutell t...@punkave.com написал: These tools already strip ?php tags, they would need minimal changes to support rolling in a .phpp file unmodified. Unless I am missing something? Sent from my iPhone On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: I posted the bellow text in other thread, but i should have it post here, so i'm reposting it to this thread. Well, it's time for me to remind about the techique many use (and some frameworks provide it out of the box) - the application file concatination to speed up file loading. Yii framework provides a Yiilite.php file for this, that includes mostly used core classes in one big file.that loads much faster and is used for production. Any other framework has user extentions or other type of solutions for this to speed up the application, and it makes really big difference. So there is a good question - how the hell in a MVC framework would i combine my models, controllers, components and other
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
Such a vote would make sense if it were clearly expressed that the final RFC would also be subject to a binding vote, so there is no risk of being forced to accept an implementation whose particular details are unacceptable to you. On Mon, Apr 16, 2012 at 5:48 PM, Arpad Ray array...@gmail.com wrote: Please excuse me for butting in without immediate context. I'd just like to support the idea of a vote on this concept without getting into specifics. If the vote is positive then we can argue the various merits of the competing RFCs knowing that we at least agree in general. On the other hand if the vote is negative, we can save a significant amount of time and effort, and can concentrate on more plausible subjects. Cheers, Arpad -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
What happens if two of them pass? On Mon, Apr 16, 2012 at 6:55 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: 16 апреля 2012 г. 22:02 пользователь Kris Craig kris.cr...@gmail.comнаписал: On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer vch...@developersdesk.com wrote: On 4/16/2012 3:31 AM, Arvids Godjuks wrote: That's sad really, to be honest. I wonder if people even use this: echo include 'foo.bar', 'baz'; Probably not, Try it! you get: 1baz It actually works more like echo (include foo.bar), 'baz'; than echo include( foo.bar), 'baz'; More important include doesn't currently allow multiple parms: include foo.bar, 'baz'; Parse error: syntax error, unexpected ',' in bla.php on line xx Rick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I'll reiterate my position that I'm not ready to bring my RFC to a vote; and even if I was, the rules wouldn't allow it. In fact, unless I'm mistaken, none of the RFCs have met the 2-week minimum requirement yet, so no vote can take place at this time. But I do think we're making progress, so I would ask for a little extra patience from the peanut gallery for now. =) To Arvids' point, I'm definitely leaning in that direction, but I'd like to hear a little bit more from anyone who believes a different approach would be better. If nobody speaks-up, I'll just assume that we have consensus on that point and add it to the RFC. Regarding include/require, I agree that any BC break would be extremely minimal. In the 10+ years I've been developing PHP, I don't think I've ever once seen somebody include multiple scripts on a single line (I wasn't even aware that such a thing was allowed). So if it does pose a change, I'd be surprised if any existing scripts would be affected. And since this is a major version increment we're talking about here, I think a small amount of allowance can be made for low-impact BC breakage IMHO. How about we just keep the parentheses optional and comma-seperate the arguments? For example, the require syntax could look like this: require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)]; Possible values for $script_type: PHP_SCRIPT_TYPE_NORMAL (0x01) - If the included file contains PHP code, parse it. PHP_SCRIPT_TYPE_TAGLESS (0x02) - Code is assumed to be PHP throughout the script. The ?php tag throws E_NOTICE and the ? tag throws E_RECOVERABLE_ERROR. PHP_SCRIPT_TYPE_STACK (0x04) - The $script_type is applied to all child scripts of the one being included. - Question : Would anyone see value in adding an override constant that, while not recommended, allows the developer to apply a different $script_type somewhere deeper in the stack? Personally this doesn't sound useful to me, but I'd be willing to put it in if enough of you wanted it. PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL PHP_SCRIPT_TYPE_TAGLESS) - The entire script is assumed to be PHP code and is parsed accordingly. PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL PHP_SCRIPT_TYPE_TAGLESS PHP_SCRIPT_TYPE_STACK) - The entire script and all its child scripts (i.e. its stack) are assumed to be PHP code and parsed accordingly. What do you think? --Kris I think there is no need for that many constants and types of inclusion. Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the later just expects the ?php at the very beginning of the file, like a header, and no other ? or ?= or ?php through the file). The KISS principle still applies, and it should be kept that way. Too many options and you end up with people abusing that on purpose with reasoning Because I can, f**k everybody else! (it's a pleasure to work with such people). I don't like the idea of removing the ?php tag at all, because it will mess up the syntax highlighting everywhere and annoy people that copy the plain code without the ?php and get it not recognized as a valid source code. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
I think updating your RFC to cover the broad points that have changed is worth it, even if small differences will continue to be expressed about the syntax. 2012/4/16 Kris Craig kris.cr...@gmail.com: 2012/4/16 Tom Boutell t...@punkave.com Kris, you have been talking recently about allowing for a mode that permits the inclusion of .php from .php... something (whatever we're calling this middle mode's recommended file extension). I think having three modes is overkill, but some people think having even two modes is overkill, so I'm prepared to live with having all three modes (traditional PHP, pure PHP that is allowed to include traditional PHP, and purest PHP that is not allowed to include traditional PHP). After all, I don't have to use purest mode if I choose not to do so - and I suspect most library authors won't because they want to write code that can include whatever the user wants it to. That's their choice and mine, and there's really no reason to deny you the option of purest mode. And one can make the argument that while, as you say, model code should never include a template, controller code (or classes in the view layer that manage templates) should invoke templates. That would give a better rationale for having all three types. However, your RFC still does not address allowing all three and currently includes very negative language about the middle option. That's because I haven't updated it since the initial draft. A second issue is that your RFC calls for file extensions to be explicitly recognized by PHP itself, which is something many people have objected to because the file extension may be unavailable or irrelevant depending on the environment. That's why my RFC addresses the file extension issue as a strongly recommended convention, not a language feature, and provides keywords that can be used to implement that convention (and really ought to provide options for the various SAPIs as well, so entry points can be pure PHP if desired). That's not actually true. What it's referring to is a convention and distinguishing between file extensions when accessed via the webserver. This is already the current behavior via handlers; the RFC isn't actually proposing to parse the filename itself at the langugage level. Though seeing as how you're the second person to have misinterpreted it to mean that, it's possible that the wording I used wasn't clear enough on that point. I think it's probably time to write an updated version of your RFC so we can figure out if we're developing common ground here. I was hoping to get a little more clarification on the inclusion method at the language level before proceeding with that. Specifically, is everybody good with using include/require as $bitwise_constant? Or do people still think the other options need to be debated more first? --Kris 2012/4/16 Kris Craig kris.cr...@gmail.com: 2012/4/16 Tom Boutell t...@punkave.com Also, Kris's proposal requires that an additional flag be tracked all the way down through the stack of requires and includes from the point where pure mode is first encountered, remembering that we're in pure mode. Note that this flag cannot be a global variable because .php files that were loaded before this .phpp file are still permitted to load things, including when acting as autoloaders on behalf of .phpp code... my head hurts. This cannot be the cleanest way to solve the problem. 2012/4/16 Tom Boutell t...@punkave.com: Oh I see. Yes, this is one of the reasons I don't like the pure can't include non-pure idea. Another reason: you can't write generic algorithms. PHP 5.4 has much improved support for anonymous functions, so we should see an increase in libraries that take a few functions as parameters and carry out an operation via those functions. But what if one of those functions requires something from a .php file? Whoops, I guess it's not a generic sorting algorithm library I just released, it's a generic sorting as long as none of your functions touch a .php file algorithm library. And good luck figuring this out when it happens. Kris has pointed out that you could still load a .php file via a function that was defined earlier in a .php file that later includes .phpp. But this just means that, like my RFC, his RFC contains a compromise about strictness. It's just that his compromise is more confusing and less likely to be understood before the user gets frustrated and declares the whole thing not worth messing with. I think .phpp files don't contain ?php and ? but can require and include files that do is a much clearer compromise, one that will get us what we want (an ever increasing percentage of .phpp files) without making enemies and generating opposition along the way to that better place. On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks
Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files
I don't think a consensus on the following points is likely to emerge without voting on them individually. I propose carrying out a vote with up to three questions to be answered depending on your response to each. We could then proceed to discuss the (relatively boring but essential) details of keywords and extensions, if any, and create a final RFC. Hopefully all parties can agree to be bound by the results of a vote on these three questions and work together to create a final RFC that abides by the result or let the matter drop. Let's briefly discuss whether these questions truly represent the major differences between the three RFCs (not the merits of those positions please) and then, I hope, carry out a vote on them so we can move on. The Questions: 1. Whether a pure code mode in which ?php is not required at the top of a file, and the ?php and ? tags are not permitted at all in such a file: * Has merit and should be pursued (option 1a), or * Should be dropped entirely (option 1b). If your vote is for option 1a, please respond to the following additional question: 2. Whether pure code mode should be: * Toggled globally by a php.ini option such that ?php and ? tags are completely forbidden when this mode is active (option 2a), or * Switched on by keywords and SAPI options that allow the sysadmin and developer to make the choice at runtime, with the ability to make that choice differently for different files or invocations, so that a mix of pure code files and files that forbid ?php and ? can exist (option 2b). 3. If your vote is for option 2b, please respond to the following additional question: Whether pure code mode should: * Forbid requiring a non-pure file from a pure file (option 3a), or * Permit requiring non-pure files from pure files (option 3b). I believe Kris Craig and Yasuo Ohgaki will find that these questions accurately sum up our really significant unreconciled differences (and, with the inclusion of question 1, the position of those who don't want the feature at all). These three questions deliberately don't address what the keywords or file extensions or other mechanisms are called exactly, because I believe those issues to be fairly simple to agree upon once we have decided the basics. On Sun, Apr 15, 2012 at 7:05 AM, Pierre Joye pierre@gmail.com wrote: hi, On Sun, Apr 15, 2012 at 1:00 PM, Kris Craig kris.cr...@gmail.com wrote: Perhaps a new list for RFC-specific discussions? =) We don't need yet a new list. Sit down together and get over your differences and create the RFC or more if you can't get over your differences. Cheers, -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
Wouldn't this be a significant performance hit when multiplied by every class file in a project? On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2012-04-13, David Muir davidkm...@gmail.com wrote: On 13/04/12 14:55, Stas Malyshev wrote: If this is a pecl module library developers cannot use it and trust that on php 5.n, it just works. That would fork the language in an undesirable way. It should be a core feature, no ini flag, no sometimes-there module. PHP 5.n is at least a year away, wide adoption of it - more like 5 years away. So if you want to write code that would run anywhere (as opposed on systems you control) you'd have to wait minimum 5 years. Wouldn't it better to have it earlier? OTOH, requiring extensions is a common thing for applications, and any pecl extension is one command away for most setups, or one download away for others. And can be made work even in 5.2 if desired. Can't it also be handled using streams to inject a leading ?php to the file prior to inclusion? A PECL extension would then just make it run a bit faster. I made this very suggestion earlier this week (we do this in ZF1 to emulate short tag support for those who use them). -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
(I'm referring to the streams approach. You seem to be suggesting a PECL extension with a fallback provision. It still sounds like something no one will seriously use because they can't count on it running fast on a given box, although it is a clever workaround.) On Fri, Apr 13, 2012 at 1:28 PM, Tom Boutell t...@punkave.com wrote: Wouldn't this be a significant performance hit when multiplied by every class file in a project? On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2012-04-13, David Muir davidkm...@gmail.com wrote: On 13/04/12 14:55, Stas Malyshev wrote: If this is a pecl module library developers cannot use it and trust that on php 5.n, it just works. That would fork the language in an undesirable way. It should be a core feature, no ini flag, no sometimes-there module. PHP 5.n is at least a year away, wide adoption of it - more like 5 years away. So if you want to write code that would run anywhere (as opposed on systems you control) you'd have to wait minimum 5 years. Wouldn't it better to have it earlier? OTOH, requiring extensions is a common thing for applications, and any pecl extension is one command away for most setups, or one download away for others. And can be made work even in 5.2 if desired. Can't it also be handled using streams to inject a leading ?php to the file prior to inclusion? A PECL extension would then just make it run a bit faster. I made this very suggestion earlier this week (we do this in ZF1 to emulate short tag support for those who use them). -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening ?php tag
On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig kris.cr...@gmail.com wrote:
This shouldn't be used to load libraries that dump raw HTML output! That
literally defeats the entire purpose. You're also assuming that all PHP
developers do 100% of their coding through pre-existing frameworks.
Consider a .phpp file that includes a .php template file when it sees
fit, in a render() method. How is this different from an echo()
statement? It's not. It's just a convenient form in some situations.
By punting these out to .php files we achieve better separation of
concerns while still respecting PHP's history as a template language
(and possible future if it improves in that area, which it may).
All I want is to stop typing ?php and dealing with whitespace
screwups above ?php. I want to do that in a way that's practical and
interoperable and which people might be able to vote for if they have
a nontrivial amount of legacy code in their life, like everybody I
work with (:
As many have pointed out, plain php template files work for some
projects. A viable RFC that people might actually vote for should
respect that. It neither picks my pocket nor breaks my leg if someone
wants to include .php template files from a .phpp file. I don't have
to do it.
When you consider that I would be completely unable to use an existing
.php library of nontrival code like Amazon's S3 SDK under your
proposal without a convoluted workaround it is pretty much a certainty
that I would have to vote no if the RFC read that way.
(Main Script)
|
|
[Included .php/HTML Script]
| |
| |
{Included .phpp Script} [Included .php/HTML Script from
Framework/Library]
This is convoluted and forces me to write a .php frontend. Surely that
is not your goal.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
I agree, there should be no limiting of unrelated language features to half-protect people who can't plan where uploads go. Sent from my iPhone On Apr 9, 2012, at 6:11 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, The only valid reason for removing ?php from PHP script would be security. I disagree here. What you are talking about here is https://www.owasp.org/index.php/Unrestricted_File_Upload So a malicious user can upload a file containing php code and fire a request which will execute it. Executing it can happen directly (you request the uploaded file via http), or indirectly (you can trick some other script to include it aka LFI which is a vulnerability in itself) For preventing the uploaded files from be executed directly, one should put the uploaded files to a separate directory and disable the php execution for that directory via the web server config (php_flag engine 0) I don't see how would the removal of the open tags prevent the malicious user from sending valid php code without opening tag. I know that in your example you mentioned valid image files containing php code with opening tag (in the image meta information), but that assumes that the code properly checks that the uploaded file is a valid image (or any other file format which can be injected with arbitrary php code). If that check doesn't happen or not entirely safe, one could inject php code even if we remove the opening tags. So imo the correct defense against these kind of attacks is: - properly handle the file upload paths, so the users can only upload files to the given directory. - turn off the php engine for that directory - properly handle your file inclusions so you don't have LFI/RFI vulnerabilities. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP class files without ?php at the top
I agree, which is why the rfc does not call for a php.ini option.
Sent from my iPhone
On Apr 9, 2012, at 3:20 AM, Arvids Godjuks arvids.godj...@gmail.com wrote:
And you get same issues that existed with magic quotes, register variables,
safe mode and other optional stuff that was required to run application when
set specificaly and it would break if something set differently. PHP just got
rid of it and you want to introduce a new optional feature that will change
how PHP behaves.
09.04.2012 9:03 пользователь Yasuo Ohgaki yohg...@ohgaki.net написал:
Hi,
2012/4/9 Tom Boutell t...@punkave.com:
Vulnerabilities in include/require should be fixed there, IMHO, not by
limiting the feature set of the language.
I'm not insisting to remove embed feature, but give a option
for programmers/administrators for better security.
If one is comfortable with current behavior, they can keep
using embed feature by default. Others who care security
may disable embed feature by optional php.ini setting or CLI
option.
Half of Morihoshi's RFC was joke, but it's a serious proposal
for people who persist better security. IMHO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
2012/4/9 Arvids Godjuks arvids.godj...@gmail.com:
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki
yohg...@ohgaki.netнаписал:
2012/4/8 Ángel González keis...@gmail.com:
On 07/04/12 22:48, Yasuo Ohgaki wrote:
Hi,
The only valid reason for removing ?php from PHP script would be
security.
Since the null byte detection for fopen, remote/local script inclusion
became much harder than before. However, it's still possible and very
easy compare to other languages. Script execution is critical security
problem and it's worth to make it better.
If there is a switch that turns off PHP's template engine nature, PHP
could be more secure than now.
php.ini
template_mode = on ; INI_ALL On by default
php -t foo.php # template mode by default
php -T foo.php # template mode off
People has option to make their code a little secure than now
or stick with current behavior.
Regards,
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Improperly configured WEB server is not the reason to change the most
basic
part of the language that will break every damn application out there.
This is not an configuration issue, but a security vulnerability that
can simply closed by disabling embed mode.
As I mentioned already, injecting malformed PHP scripts into files
is too easy compare to other languages. This could be improved
by simple modification and we can maintain compatibility with it.
I don't see anything wrong here.
Yet another PHP script injection example.
There are many applications that store user inputs in $_SESSION.
Attacker can inject PHP script into $_SESSION, then locally include
it. This is easy since attacker knew their session ID and path to
session file is can be guessed easily. All attacker has to do is
finding a vulnerable include()/require() to attack.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
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] RFC: source files without opening tag
.phpp would be fine. .phpp code needs to be able to interoperate with .php templates, otherwise one can't supply reusable libraries that implement generic algorithms without surprises for those who integrate them in older projects. Sent from my iPhone On Apr 9, 2012, at 1:16 AM, Kris Craig kris.cr...@gmail.com wrote: Tom, On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell t...@punkave.com wrote: Thanks. However, would you please fix the summary on the RFC's page to match the summary in the actual RFC? As you have written it, it implies that support for ?php would be completely removed. This is not the case. As for adding a boolean parameter to the require keyword, as the RFC mentions there are already at least two distinctions already when requiring files in PHP: * include vs. require behavior (warning vs. error on failure) * once vs. every time (require_once vs. require) And we are proposing a third: * start in php mode vs. start in html mode We already have four keywords for requiring files. At this point it does not make sense to keep introducing more keywords (we would need 8 with this change). Your boolean flag proposal keeps it to four keywords, but as soon as someone adds another flag it will become awkward to remember them. Since PHP does not have named parameters I think an associative array is the best way to go (especially with the new short syntax). Also I don't think it makes sense to forbid shifting into html mode later in the file, it could reduce support for the proposal needlessly - since it already lets people who want to write clean all-PHP files do so, and some of those people might have legitimate reasons to use HTML mode in the scope of a function or method (where it does not suddenly introduce whitespace without being explicitly called, etc). But if it really came down to it I could live with an absolutely nothing but PHP behavior when the code flag is true (supporting ?php when the flag is not set is a must of course). On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, I talked on twitter. Yes, he is kidding, but he is serious, too. I've added the RFC to Under Discussion and added security issue description. I also added my proposal that controls embed mode. BTW, I don't think we need new require_path why don't we use require file.php, ture; or some thing similar? I prefer to use switch, since security countermeasure is better to be enforced by switch. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: Hi, Moriyoshi has created same entry on 4/1, but it seems it was deleted already. Anyway, he had a patch for it. https://gist.github.com/2266652 As I mentioned in other thread, we should better to have a switch to disable embed mode for security reasons. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure what the requirements are to get it added to the Under Discussion session and get the ball rolling formally. Please enlighten and I'll do whatever is required. Thanks! -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com
Re: [PHP-DEV] RFC: source files without opening tag
I think separating these rfcs makes sense, thanks. Sent from my iPhone On Apr 9, 2012, at 2:17 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tom, It's better to distinguish security related issue and others. Therefore, I listed Moriyoshi's proposal to RFC list and put my proposal in it. His proposal is almost the same as mine except the flag for embed mode control. https://wiki.php.net/rfc/nophptags I recovered the original except for adding references to No PHP Tags RFC. https://wiki.php.net/rfc/source_files_without_opening_tag This makes discussion more clear to everyone, I hope. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: source files without opening tag
I would like to clarify what this RFC actually says. Let's try to keep
this thread to the pros and cons of this specific proposal.
The following new keyword would be introduced:
require_path
This keyword has two parameters of which the second is optional. The
first parameter is the path (filename or URL) to be required, and
behaves exactly as the sole parameter of the require keyword behaves.
The second parameter is an associative array.
If this second parameter is absent, require_path behaves exactly like require.
If the second parameter is present, the following keys may optionally
be present in the array, with the following effects:
If 'once' is present and true, the specified path is loaded no more
than once, exactly like require_once.
If 'warn' is present and true, a loading or compilation error results
in E_WARNING (per the current behavior of the include keyword). If
warn is absent or false, a loading or compilation error results in
E_COMPILE_ERROR (per the current behavior of the require keyword).
If 'code' is present and true, the parser begins reading the file as
if a ?php open tag had already been encountered. If code is absent or
false, the parser reads the file beginning in “HTML mode,” exactly as
the require keyword does today.
Examples:
// Behaves just like require
require_path 'filename.php';
// Behaves just like include_once
require_path 'filename.php', array('warn' = true, 'once' = true);
// Loads a file starting out in PHP mode so the opening ?php is not required
require_path 'filename.php', array('code' = true);
In addition, a convention (not a requirement checked by the code)
would be encouraged: PHP source code files without an initial ?php
would be named with a .phpc file extension.
That's all the RFC calls for. The rest of it is just responses to
frequently raised concerns:
https://wiki.php.net/rfc/source_files_without_opening_tag
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: source files without opening tag
On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer vch...@developersdesk.com wrote: Option 1: Introduce require_path I think require_code is a better name. Parm 1 isn't a path, it is a file, so require_path seems wrong to me. Yeah, you're not the first to say this. require_file and require_code have both been suggested. I'm fine with either really. I'd prefer a 'start in code mode' optional second parameter to include[_once] and require[_once]. That would be fine as far as my goals here go, but I'm concerned that we'll just repeat this discussion if any other options for requiring things come into being (: Option 2: Filename Convention The PHP engine should not know or care what the file extension is. I won't object if you can convince autoloader authors to follow the .phpc convention. Personally, once I can count on this feature, every file I include/require will probably be written starting in code mode and using the new calling convention. Even when I use PHP to create page templates... Sounds like you're basically OK with that bit. Additional suggestions: Add an option so the CLI can start in code mode too. Add another Handler to the Apache SAPI, maybe application/x-httpd-php-code similar to x-httpd-php and x-httpd-php-source, so we can configure Apache to start arbitrary file extensions with code mode on. This defers setting the action for various file extensions to the person configuring the web server. Other web server SAPIs will need similar treatment, but I'll leave them to someone with personal experience. I'm not opposed to these suggestions. I was trying to keep it conservative and simple to implement and focus on the case where it bugs me (creating libraries of class files), but I'd be happy to see a way for .phpc to be the entry point / frontend controller / standalone script as well. As you say it must be done with SAPI options (the CLI included), not hardcoded file extension checking. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Object oriented page templates in PHP
There has been talk of making PHP a better templating language. After all, it did start out there. Folks have mentioned ideas like making it easier to output escaped content, etc., but these are all hardcoded solutions. And one of the biggest problems with PHP as a template language is that when best practices change, you're stuck with the helper functions you already have unless you start globally replacing things. You can't really subclass or override a function. So even frameworks that provide helper functions in the vein of Symfony 1 (which borrowed the idea from Rails) get stuck when you want to alter the behavior. Last year I did a project in a one-off MVC framework of my own in which I decided I didn't want to be stuck with that, so I made a rule: anything I wanted to call from the template had to be a method of $this, the view object in whose render() method the template file was require()'d. This turned out to be a good thing. By writing ?php $this-escape($foo) ?, I was able to benefit from whatever implementation of 'escape' the subclass of view in question decided to supply to me. But of course it is very verbose and a templating language that is too tedious to use won't get used. What if PHP supported a short tag for calling a method of $this? Then one could write: ?@escape($foo) ? And 'escape' could be upgraded and modified as needed in an object oriented way without the need to type ?php $this- many times. A problem with this proposal is that it does not address nesting. One still has to write: ?@addLinks($this-escape($foo)) ? And it is fairly common to combine such operations. So maybe I should just define a sublimetext shortcut for: ?php $this- And be done with it. (: It detracts from readability relative to a template language like Twig, but I can always choose to use Twig. This would be notably easier if PHP, like Java and C++, called methods of the current object implicitly without the need for $this-. But of course that would be too great a change as there would be no way to make existing code work correctly again if it reasonably expected implode() to call the usual PHP function and not a method. Plus it's probably a real pain to implement in general. Thoughts? -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
John, please take a look at the RFC: https://wiki.php.net/rfc/source_files_without_opening_tag I am not proposing any backwards-incompatible changes that would affect existing code. Code that isn't interested need not ever take advantage of the feature and can interoperate with code that does. I realize there is confusion about this because of a separate and unrelated RFC to actually eliminate ?php. I agree that the security argument is bogus, but it was never one of my reasons for this proposal. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object oriented page templates in PHP
There's a reason I didn't try to kick this out as a fully formed RFC (:
The choice of @ is a nonstarter, yes. I forgot that ? is a valid
start code for PHP already so it is already valid PHP to write ?@.
And I have no solution for the nesting problem. It's just an
interesting issue; if it had a good solution PHP might be a convenient
and extensible templating language, as well as being a fast one.
I don't think an explicit syntax for this would be magic, however
terse it might be. Calling methods implicitly like Java does, that's
magic (:
On Mon, Apr 9, 2012 at 12:03 PM, Paul Dragoonis dragoo...@gmail.com wrote:
-1.
PHP doesn't need more magic.
On Mon, Apr 9, 2012 at 4:53 PM, Nikita Popov nikita@googlemail.com
wrote:
On Mon, Apr 9, 2012 at 5:10 PM, Tom Boutell t...@punkave.com wrote:
What if PHP supported a short tag for calling a method of $this?
Then one could write:
?@escape($foo) ?
A big -1 on this.
If you want to roll your own template syntax, just do so. It's not
that hard to run a quick str_replace('?@', '?php echo $this-',
$code) over the template.
Especially consider that @ is already used for error suppression, so
code that previously just wanted to suppress some errors will suddenly
try to call class methods (which obviously will lead to fatal errors).
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
It sounds like you are proposing to gradually kill the use of PHP for templating entirely, which I don't think is something people would vote for. I sometimes use perfectly good older frameworks that do use .php files for templating in a reasonable way, and I'm one of the advocates for migrating away from starting everything with ?php. I would have to vote against it myself. There's no reason to kill good code that passes its tests just because it uses inline HTML. I won't even know I have that code in my project from some third party library until I find out the hard way. No, just no. (: I did propose one new keyword, but by proposing one keyword with a future-friendly syntax instead of four new keywords I'm attempting to help with the pollution problem. On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott l...@cywh.com wrote: Tom, As I've said before I don't think new keywords are the answer. They will just pollute the language even further. I also don't think an ini setting is a bad thing either. It is often used in PHP as a way to transition from way of doing things to another. First you introduce it with it being off by default, then on by default, then deprecate the old behavior. It's quite normal in PHP's history. In another email someone mentioned doing two rfcs. In both cases are we talking about removing ?php ? Because it's become somewhat confusing to keep track of what is being talked about. If that is the case, continue reading. I would prefer the starting ?php tag be optional rather than removed. Just explicitly forbid the ending ? tag and treat text before the opening ?php tag differently. Perhaps ignore it (rather than print) or throw an error. That is at least how I would prefer the code mode as most non-template files only start with ?php. It allows for backwards compatibility. If you must add keywords it should be something like require_template NOT require_code/require_file. Templates are the exception, not the norm. Luke Scott On Apr 8, 2012, at 9:32 AM, Tom Boutell t...@punkave.com wrote: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure what the requirements are to get it added to the Under Discussion session and get the ball rolling formally. Please enlighten and I'll do whatever is required. Thanks! -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
I see what you're saying, but you're proposing a new keyword to
include code that does what plain old 'require' does now (assuming
it's not a nice clean class file that is being included). Which means
that valid code today is busted code once this feature comes out. That
seems like a very hard sell.
On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott l...@cywh.com wrote:
On Apr 9, 2012, at 9:16 AM, Tom Boutell t...@punkave.com wrote:
It sounds like you are proposing to gradually kill the use of PHP for
templating entirely, which I don't think is something people would
vote for.
I'm not saying that at all. I'm saying that PHP code should be clearly
separated from template code. ?php should be optional at the start of
the file and IF a keyword should be added it should be for templates
and short-tags.
99% of modern PHP code is going to be classes that start with ?php
and omit the ending ? (since PHP 5 due to how easy it is for white
space to end up on the tail end of a file). this is even the case with
procedural code.
Half the PHP frameworks out there have their own template engine
because they can do a lot more than what short tags offer. Example:
Twig offers template inheritance.
Introducing a keyword for PHP code without the ?php tag is
impractical. It makes much more sense to have a keyword for templates.
For non-template code the starting ?php tag should always work as it
has before for backwards compatibility. The difference is you cannot
use ? and text before the opening ?php tag is either ignored or
throws an error.
I sometimes use perfectly good older frameworks that do use
.php files for templating in a reasonable way, and I'm one of the
advocates for migrating away from starting everything with ?php. I
would have to vote against it myself.
And those files can be included with something like require_template
or you can turn off the option in the ini file.
The point is in EITHER MODE a php file that starts with ?php will
work as it did before. The new mode would just disallow you to break
out of PHP code with ?.
There's no reason to kill good
code that passes its tests just because it uses inline HTML. I won't
even know I have that code in my project from some third party library
until I find out the hard way. No, just no. (:
I'm not trying to kill anything. In fact what I'm proposing would be a
smooth transition to something that is already done. The difference is
at some point you won't be able to do this:
?php
class Object
{
public function output()
{
?
Print me!
?php
}
}
I cringe every time I see this. There is no excuse since we have here/nowdocs.
For people that use PHP as a template there can be other options. I'm
not totally against a new keyword, but I am against a new keyword for
including normal PHP code. It just doesn't make sense. No matter what
you name it (require_code, require_file, require_path) it's damned
confusing. If you did it the other way around its much clearer:
require_template.
With require_template you're also free to expand template
functionality while keeping code clearly separated.
I did propose one new keyword, but by proposing one keyword with a
future-friendly syntax instead of four new keywords I'm attempting to
help with the pollution problem.
It's not as much as adding a keyword as it is what keyword you're adding.
I hope the way I've explained things makes sense.
Luke
On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott l...@cywh.com wrote:
Tom,
As I've said before I don't think new keywords are the answer. They
will just pollute the language even further.
I also don't think an ini setting is a bad thing either. It is often
used in PHP as a way to transition from way of doing things to
another. First you introduce it with it being off by default, then on
by default, then deprecate the old behavior. It's quite normal in
PHP's history.
In another email someone mentioned doing two rfcs. In both cases are
we talking about removing ?php ? Because it's become somewhat
confusing to keep track of what is being talked about. If that is the
case, continue reading.
I would prefer the starting ?php tag be optional rather than removed.
Just explicitly forbid the ending ? tag and treat text before the
opening ?php tag differently. Perhaps ignore it (rather than print)
or throw an error.
That is at least how I would prefer the code mode as most
non-template files only start with ?php. It allows for backwards
compatibility.
If you must add keywords it should be something like require_template
NOT require_code/require_file. Templates are the exception, not the
norm.
Luke Scott
On Apr 8, 2012, at 9:32 AM, Tom Boutell t...@punkave.com wrote:
I have written an RFC proposing backwards-compatible support for
source files without an opening ?php tag:
https://wiki.php.net/rfc/source_files_without_opening_tag
This RFC is not yet listed at https://wiki.php.net/rfc. I am
Re: [PHP-DEV] RFC: source files without opening tag
Also, your objection - that 'require_code' is confusing - would most
likely be an issue for a handful of people who write autoloaders.
Those clean PHP class files are almost always autoloaded.
On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell t...@punkave.com wrote:
I see what you're saying, but you're proposing a new keyword to
include code that does what plain old 'require' does now (assuming
it's not a nice clean class file that is being included). Which means
that valid code today is busted code once this feature comes out. That
seems like a very hard sell.
On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott l...@cywh.com wrote:
On Apr 9, 2012, at 9:16 AM, Tom Boutell t...@punkave.com wrote:
It sounds like you are proposing to gradually kill the use of PHP for
templating entirely, which I don't think is something people would
vote for.
I'm not saying that at all. I'm saying that PHP code should be clearly
separated from template code. ?php should be optional at the start of
the file and IF a keyword should be added it should be for templates
and short-tags.
99% of modern PHP code is going to be classes that start with ?php
and omit the ending ? (since PHP 5 due to how easy it is for white
space to end up on the tail end of a file). this is even the case with
procedural code.
Half the PHP frameworks out there have their own template engine
because they can do a lot more than what short tags offer. Example:
Twig offers template inheritance.
Introducing a keyword for PHP code without the ?php tag is
impractical. It makes much more sense to have a keyword for templates.
For non-template code the starting ?php tag should always work as it
has before for backwards compatibility. The difference is you cannot
use ? and text before the opening ?php tag is either ignored or
throws an error.
I sometimes use perfectly good older frameworks that do use
.php files for templating in a reasonable way, and I'm one of the
advocates for migrating away from starting everything with ?php. I
would have to vote against it myself.
And those files can be included with something like require_template
or you can turn off the option in the ini file.
The point is in EITHER MODE a php file that starts with ?php will
work as it did before. The new mode would just disallow you to break
out of PHP code with ?.
There's no reason to kill good
code that passes its tests just because it uses inline HTML. I won't
even know I have that code in my project from some third party library
until I find out the hard way. No, just no. (:
I'm not trying to kill anything. In fact what I'm proposing would be a
smooth transition to something that is already done. The difference is
at some point you won't be able to do this:
?php
class Object
{
public function output()
{
?
Print me!
?php
}
}
I cringe every time I see this. There is no excuse since we have
here/nowdocs.
For people that use PHP as a template there can be other options. I'm
not totally against a new keyword, but I am against a new keyword for
including normal PHP code. It just doesn't make sense. No matter what
you name it (require_code, require_file, require_path) it's damned
confusing. If you did it the other way around its much clearer:
require_template.
With require_template you're also free to expand template
functionality while keeping code clearly separated.
I did propose one new keyword, but by proposing one keyword with a
future-friendly syntax instead of four new keywords I'm attempting to
help with the pollution problem.
It's not as much as adding a keyword as it is what keyword you're adding.
I hope the way I've explained things makes sense.
Luke
On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott l...@cywh.com wrote:
Tom,
As I've said before I don't think new keywords are the answer. They
will just pollute the language even further.
I also don't think an ini setting is a bad thing either. It is often
used in PHP as a way to transition from way of doing things to
another. First you introduce it with it being off by default, then on
by default, then deprecate the old behavior. It's quite normal in
PHP's history.
In another email someone mentioned doing two rfcs. In both cases are
we talking about removing ?php ? Because it's become somewhat
confusing to keep track of what is being talked about. If that is the
case, continue reading.
I would prefer the starting ?php tag be optional rather than removed.
Just explicitly forbid the ending ? tag and treat text before the
opening ?php tag differently. Perhaps ignore it (rather than print)
or throw an error.
That is at least how I would prefer the code mode as most
non-template files only start with ?php. It allows for backwards
compatibility.
If you must add keywords it should be something like require_template
NOT require_code/require_file. Templates are the exception, not the
norm.
Luke Scott
On Apr 8, 2012, at 9:32 AM
Re: [PHP-DEV] PHP class files without ?php at the top
On Mon, Apr 9, 2012 at 12:43 PM, John Crenshaw johncrens...@priacta.com wrote: interoperability is somewhat reduced in the sense that all 3rd party code would have to be checked for the ?php I'm not sure what you mean by this part exactly? -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Ralph, you make good points. And Luke's opposition to my new keyword is probably going to be shared by others (like Chris who just chimed in). So the more I think about it, the more a set of constants that can be OR'd together is a better idea than my associative array proposal. And it's best to keep the original four keywords, adding the second, optional parameter as a way of passing a combination of flags that alter their behavior. Also that set of bits could include the 'once' and 'warning' flags, so if you really want to just use the 'require' keyword and determine dynamically which behavior you get, you can. So there are no new keywords needed. Also, the presence of any bit that is not recognized by this version of PHP should be an error. It's better to stop than to completely misparse a file (: I don't think long-ish constants are a real problem since this functionality would very likely be written just a few times in autoloaders (as is typical in almost any project that would be interested in .phpc files in the first place) rather than repeatedly all over the place in every file (as with old-fashioned uses of 'require', and various templating situations). I will revise the RFC shortly. On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott l...@cywh.com wrote: On Apr 9, 2012, at 10:44 AM, Ralph Schindler ra...@ralphschindler.com wrote: Hey Tom, An idea, why not overload require/include with a second parameter that simply enforces an include mode. For example // in some autoloader (include, requires, and *_onces) include $pathToFile, INCLUDE_MODE_PHP_ONLY; This would tell the parser/executor to start in PHP mode and never leave it, that way, ending tags would throw a runtime/execution error. Other constants and behaviors could be: INCLUDE_MODE_PHP_START; INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior) This would have the least amount of impact on BC, and seeminlyg would be a friendly change to the lexer/syntax. Thoughts? If this were to happen: - I would prefer much shorter elegant constants. - A constant for suppressing warnings thrown by include without suppressing warnings/errors by the actual file -- I think we can all agree @include is counter productive since it does much more that suppress warnings thrown by include (even parse errors!). Luke -ralph On 4/9/12 12:23 PM, Tom Boutell wrote: Also, your objection - that 'require_code' is confusing - would most likely be an issue for a handful of people who write autoloaders. Those clean PHP class files are almost always autoloaded. On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutellt...@punkave.com wrote: I see what you're saying, but you're proposing a new keyword to include code that does what plain old 'require' does now (assuming it's not a nice clean class file that is being included). Which means that valid code today is busted code once this feature comes out. That seems like a very hard sell. On Mon, Apr 9, 2012 at 1:10 PM, Luke Scottl...@cywh.com wrote: On Apr 9, 2012, at 9:16 AM, Tom Boutellt...@punkave.com wrote: It sounds like you are proposing to gradually kill the use of PHP for templating entirely, which I don't think is something people would vote for. I'm not saying that at all. I'm saying that PHP code should be clearly separated from template code.?php should be optional at the start of the file and IF a keyword should be added it should be for templates and short-tags. 99% of modern PHP code is going to be classes that start with?php and omit the ending ? (since PHP 5 due to how easy it is for white space to end up on the tail end of a file). this is even the case with procedural code. Half the PHP frameworks out there have their own template engine because they can do a lot more than what short tags offer. Example: Twig offers template inheritance. Introducing a keyword for PHP code without the?php tag is impractical. It makes much more sense to have a keyword for templates. For non-template code the starting?php tag should always work as it has before for backwards compatibility. The difference is you cannot use ? and text before the opening?php tag is either ignored or throws an error. I sometimes use perfectly good older frameworks that do use .php files for templating in a reasonable way, and I'm one of the advocates for migrating away from starting everything with?php. I would have to vote against it myself. And those files can be included with something like require_template or you can turn off the option in the ini file. The point is in EITHER MODE a php file that starts with?php will work as it did before. The new mode would just disallow you to break out of PHP code with ?. There's no reason to kill good code that passes its tests just because it uses inline HTML. I won't even know I have that code in my project from some third party library until I find out the hard way. No, just no. (: I'm not trying
Re: [PHP-DEV] Object oriented page templates in PHP
It definitely can be, yeah. I thought perhaps I'd hit on a way to do it without as much redundant userland code to duplicate PHP's templating behavior first and then make it better. But it's probably not realistic to hardcode this one. No two people agree on templating languages for long (: On Mon, Apr 9, 2012 at 1:49 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2012-04-09, Tom Boutell t...@punkave.com wrote: There's a reason I didn't try to kick this out as a fully formed RFC (: The choice of @ is a nonstarter, yes. I forgot that ? is a valid start code for PHP already so it is already valid PHP to write ?@. Another tack to take is to use PHP's streams support. We did this in ZF's Zend_View at one point to emulate short tags when they're disabled. Basically, it allows you to pre-process the template file as it's being included. The downside is, of course, performance. However, you could very easily add a caching layer to this as well to cache the modified code so that subsequent calls do not have to do the pre-processing. Basically, I think this is something that can be accomplished in userland. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
Such code would have the .phpc extension, so it wouldn't get loaded at all by most autoloaders that aren't prepared for it I imagine. This feature would certainly make the most sense as part of a new version of PHP that introduces other new functionality. I'm going to use feature X in this code, which doesn't exist in version Y anyway, so I may as well take advantage of not having to type ?php anymore as well. On Mon, Apr 9, 2012 at 1:33 PM, John Crenshaw johncrens...@priacta.com wrote: From: Tom Boutell [mailto:t...@punkave.com] On Mon, Apr 9, 2012 at 12:43 PM, John Crenshaw johncrens...@priacta.com wrote: interoperability is somewhat reduced in the sense that all 3rd party code would have to be checked for the ?php I'm not sure what you mean by this part exactly? Suppose a code library is written and the author writes it without the ?php at the head of each file. Using that library in a project that opted to keep the ?php requires adding this to the head of each file, or else ensuring that the library is always included with the code parameter set (which could get really messy with autoloaders.) Additionally (assuming that you modified the code files) updating the library in the future gets really messy. It's not the end of the world, but it's frustrating. I'd like to believe that most library authors will be smart enough to always include the ?php for compatibility purposes, but I'm sure some won't. John Crenshaw Priacta, Inc. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
Agreed, I will respond only on the RFC thread. On Mon, Apr 9, 2012 at 4:45 PM, Kris Craig kris.cr...@gmail.com wrote: On Mon, Apr 9, 2012 at 4:11 AM, Pierre Joye pierre@gmail.com wrote: hi! On Mon, Apr 9, 2012 at 12:48 PM, Tom Boutell t...@punkave.com wrote: I agree, which is why the rfc does not call for a php.ini option. Can we kill this thread and focus only on the RFC one please? Thanks. +1 We've got 2 active threads discussing the same idea. Let's move further replies to the one linking to the RFC so it's easier to follow, ok? Thanks! --Kris Cheers, -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
This is an attempt to protect people who have written inherently insecure code
anyway. One should never do a dynamic require to any untrusted location, if
ever at all, yes?
Sent from my iPhone
On Apr 8, 2012, at 8:00 AM, Ángel González keis...@gmail.com wrote:
2012/4/8, Yasuo Ohgaki:
2012/4/8 Ángel González keis...@gmail.com:
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
Yes, but if I properly check that there's no '?php' in the uploaded files
(as you should verify everything you allow users to upload), it can't be
exploited.
OTOH if the vulnerable include is not an include but an include_code,
they could
use a file which was
exec(rm -rf); // Example of what not to do
And was happily uploaded as plain text.
--
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
[PHP-DEV] Creating an RFC: do I need to be blessed somehow?
Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? Thanks. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Creating an RFC: do I need to be blessed somehow?
Thanks, I have access now. Do I need to have a patch in hand before publicizing an RFC? On Sun, Apr 8, 2012 at 10:56 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't get a create this page button. Is this the right place for me to start an RFC? Thanks. Hi, could somebody with wiki admin access give Tom rfc karma? thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: source files without opening tag
I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure what the requirements are to get it added to the Under Discussion session and get the ball rolling formally. Please enlighten and I'll do whatever is required. Thanks! -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
I don't think I have the privilege of editing the main page that lists all the RFCs. The template should probably say In Draft rather than starting out with the wrong status (: On Sun, Apr 8, 2012 at 5:10 PM, Kris Craig kris.cr...@gmail.com wrote: As far as I know, you've already met that req by posting the RFC here, so go ahead and add it. In the future, remember there's also an In Draft status for RFCs that haven't been announced here yet. :) On Apr 8, 2012 9:32 AM, Tom Boutell t...@punkave.com wrote: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure what the requirements are to get it added to the Under Discussion session and get the ball rolling formally. Please enlighten and I'll do whatever is required. Thanks! -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
Vulnerabilities in include/require should be fixed there, IMHO, not by
limiting the feature set of the language.
On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
2012/4/9 Arvids Godjuks arvids.godj...@gmail.com:
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohg...@ohgaki.netнаписал:
2012/4/8 Ángel González keis...@gmail.com:
On 07/04/12 22:48, Yasuo Ohgaki wrote:
Hi,
The only valid reason for removing ?php from PHP script would be
security.
Since the null byte detection for fopen, remote/local script inclusion
became much harder than before. However, it's still possible and very
easy compare to other languages. Script execution is critical security
problem and it's worth to make it better.
If there is a switch that turns off PHP's template engine nature, PHP
could be more secure than now.
php.ini
template_mode = on ; INI_ALL On by default
php -t foo.php # template mode by default
php -T foo.php # template mode off
People has option to make their code a little secure than now
or stick with current behavior.
Regards,
How does it help security?
If any, requiring '?php' before executable code makes easier to filter
out malicious files on apps with uploads in case there's a local
inclusion vulnerability somewhere.
Attackers may inject PHP script almost anything/anywhere since
PHP code may be embed anywhere in a file.
For example, malicious PHP script may be in GIF something like
gif89a ...any data.. ?php exec('rm -rf /') ?
and all attacker have to do is include/require the data somehow.
Attacker cannot do that this for other languages, since they are
not a embedded language. I know case that attackers may inject
malicious perl/ruby script in data files, but PHP is too easy
compare to these languages.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Improperly configured WEB server is not the reason to change the most basic
part of the language that will break every damn application out there.
This is not an configuration issue, but a security vulnerability that
can simply closed by disabling embed mode.
As I mentioned already, injecting malformed PHP scripts into files
is too easy compare to other languages. This could be improved
by simple modification and we can maintain compatibility with it.
I don't see anything wrong here.
Yet another PHP script injection example.
There are many applications that store user inputs in $_SESSION.
Attacker can inject PHP script into $_SESSION, then locally include
it. This is easy since attacker knew their session ID and path to
session file is can be guessed easily. All attacker has to do is
finding a vulnerable include()/require() to attack.
Regards,
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: Hi, Moriyoshi has created same entry on 4/1, but it seems it was deleted already. Anyway, he had a patch for it. https://gist.github.com/2266652 As I mentioned in other thread, we should better to have a switch to disable embed mode for security reasons. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure what the requirements are to get it added to the Under Discussion session and get the ball rolling formally. Please enlighten and I'll do whatever is required. Thanks! -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Thanks. However, would you please fix the summary on the RFC's page to match the summary in the actual RFC? As you have written it, it implies that support for ?php would be completely removed. This is not the case. As for adding a boolean parameter to the require keyword, as the RFC mentions there are already at least two distinctions already when requiring files in PHP: * include vs. require behavior (warning vs. error on failure) * once vs. every time (require_once vs. require) And we are proposing a third: * start in php mode vs. start in html mode We already have four keywords for requiring files. At this point it does not make sense to keep introducing more keywords (we would need 8 with this change). Your boolean flag proposal keeps it to four keywords, but as soon as someone adds another flag it will become awkward to remember them. Since PHP does not have named parameters I think an associative array is the best way to go (especially with the new short syntax). Also I don't think it makes sense to forbid shifting into html mode later in the file, it could reduce support for the proposal needlessly - since it already lets people who want to write clean all-PHP files do so, and some of those people might have legitimate reasons to use HTML mode in the scope of a function or method (where it does not suddenly introduce whitespace without being explicitly called, etc). But if it really came down to it I could live with an absolutely nothing but PHP behavior when the code flag is true (supporting ?php when the flag is not set is a must of course). On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, I talked on twitter. Yes, he is kidding, but he is serious, too. I've added the RFC to Under Discussion and added security issue description. I also added my proposal that controls embed mode. BTW, I don't think we need new require_path why don't we use require file.php, ture; or some thing similar? I prefer to use switch, since security countermeasure is better to be enforced by switch. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Yasuo Ohgaki yohg...@ohgaki.net: Hi, Moriyoshi has created same entry on 4/1, but it seems it was deleted already. Anyway, he had a patch for it. https://gist.github.com/2266652 As I mentioned in other thread, we should better to have a switch to disable embed mode for security reasons. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell t...@punkave.com: I have written an RFC proposing backwards-compatible support for source files without an opening ?php tag: https://wiki.php.net/rfc/source_files_without_opening_tag This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure what the requirements are to get it added to the Under Discussion session and get the ball rolling formally. Please enlighten and I'll do whatever is required. Thanks! -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
Neat idea. I have considered writing persistent php servers that just accept requests serially. Possibly you could write a fastcgi server in pure php. That would still delegate most of the grunt work to apache. Sent from my iPhone On Apr 6, 2012, at 7:46 PM, Luke Scott l...@cywh.com wrote: I've spent the last few days pouring over the Zend engine source code. I think I have a basic understanding on the memory management. Likely what I say may be incorrect, so I apologize in advance. What I'm trying to do is write an extension to persist PHP variables past the end of the request in the SAPI to be used on the next request (different user, same process). I'd like to do this without serialization. The reason is certain objects in PHP (in a framework, for example) are not request specific and it would be useful to have these objects already loaded and usable without having to construct them on every request. (Sample use case: Dependency injection like Guice without having to write physical containers - using reflection, written in PHP) From what I've gathered thus far, it is impossible to do without copying the non-persistent memory into persistent memory, and then back again. I'm assuming this is because all the memory associated with PHP variables use emalloc, which places it onto a stack that is disposed of at the end of the request. So there seems to only be two ways to do this: 1 - Copy non-persistent memory into persistent memory (and back) using a deep copy. Probably not very efficient. May not be much better than serialization. 2 - Modify the Zend engine to flag objects/zvals as persistent so they aren¹t thrown away until the process ends. #2 seems to be the better way to go. #1 seems to be the only way to do it as an extension (maintaining its own stack). There seems to have been some discussion (7 years ago) of this mentioned here under 6.9: http://www.php.net/~derick/meeting-notes.html I've been able to do it somewhat with string zvals, but objects are a different story (given that a zval contains a handle index referring an entry in a bucket). The goal, at least with objects, is the objects doesn't destruct until the end of the process. With copying memory it looks like I'd probably have to copy the object into my own bucket, modify the original in zend's bucket so the destructor isn't called (destructor_callled = 1), and then at the start of the request copy what's in my bucket into zend's bucket. At this point I feel light a mad scientist. I'm hoping to gain some insight on how this might be done properly with PHP 5.3/5.4 (or just 5.4) - even if it involves modifying the Zend engine. Have you guys had any recent discussions about doing this? Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
Indeed phpdaemon.net appears to cover this ground, although your idea might deliver higher performance. Sent from my iPhone On Apr 6, 2012, at 7:46 PM, Luke Scott l...@cywh.com wrote: I've spent the last few days pouring over the Zend engine source code. I think I have a basic understanding on the memory management. Likely what I say may be incorrect, so I apologize in advance. What I'm trying to do is write an extension to persist PHP variables past the end of the request in the SAPI to be used on the next request (different user, same process). I'd like to do this without serialization. The reason is certain objects in PHP (in a framework, for example) are not request specific and it would be useful to have these objects already loaded and usable without having to construct them on every request. (Sample use case: Dependency injection like Guice without having to write physical containers - using reflection, written in PHP) From what I've gathered thus far, it is impossible to do without copying the non-persistent memory into persistent memory, and then back again. I'm assuming this is because all the memory associated with PHP variables use emalloc, which places it onto a stack that is disposed of at the end of the request. So there seems to only be two ways to do this: 1 - Copy non-persistent memory into persistent memory (and back) using a deep copy. Probably not very efficient. May not be much better than serialization. 2 - Modify the Zend engine to flag objects/zvals as persistent so they aren¹t thrown away until the process ends. #2 seems to be the better way to go. #1 seems to be the only way to do it as an extension (maintaining its own stack). There seems to have been some discussion (7 years ago) of this mentioned here under 6.9: http://www.php.net/~derick/meeting-notes.html I've been able to do it somewhat with string zvals, but objects are a different story (given that a zval contains a handle index referring an entry in a bucket). The goal, at least with objects, is the objects doesn't destruct until the end of the process. With copying memory it looks like I'd probably have to copy the object into my own bucket, modify the original in zend's bucket so the destructor isn't called (destructor_callled = 1), and then at the start of the request copy what's in my bucket into zend's bucket. At this point I feel light a mad scientist. I'm hoping to gain some insight on how this might be done properly with PHP 5.3/5.4 (or just 5.4) - even if it involves modifying the Zend engine. Have you guys had any recent discussions about doing this? Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP class files without ?php at the top
Now that the flamewar has died down a little I'd like to try to have a civil discussion about this idea - *without* my admittedly inflammatory suggestion to kill ?php altogether. So here is what I am seriously suggesting: * The default behavior doesn't change. The parser starts out in HTML mode. * If the CLI sees a .phpc file extension, the parser starts out in PHP mode (no opening ?php is required). It is still possible to shift into HTML mode after that with ?. * If a require/include statement sees a .phpc file extension, the parser starts out in PHP mode. * If mod_php and FPM are able to see the path (I'm honestly not sure if they can or not), they look for .phpc as their indication to start out in PHP mode. If that's not possible then new options are defined to allow Apache to be configured to tell mod_php and/or FPM to do the right thing based on mime types etc. This way .php continues to behave exactly as it does today, and can interoperate smoothly with code that uses .phpc. .phpc can require .php and vice versa. They are friends. Thoughts? -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
From the viewpoint of someone writing reusable classes, the need to start with ?php and reprimand anybody who accidentally puts a newline above it is a silly annoyance they don't experience with other tools. That said, you are making valid points, I'm not convinced myself that file extensions necessarily should or could be determined in every context. But it seems the most viable way of addressing the issue - if a viable way even exists. Partly I want to convince myself that this either can or can't ever be improved, and move on either way (: On Sat, Apr 7, 2012 at 9:35 AM, Crocodile crocodil...@gmail.com wrote: Hello, Tom... Are you seriously that bothered with '?php' at the top of your classes? Are you serious when talking changing reguire/include behaviour just to satisfy your wish? To be also serious, I would mention the possibility of including URLs. There is no such thing as file name extension in URLs. Thus your idea should be forgot. Personally, I really think 1st of April is like continuing in the internals mailing list... 2012/4/7 Tom Boutell t...@punkave.com Now that the flamewar has died down a little I'd like to try to have a civil discussion about this idea - *without* my admittedly inflammatory suggestion to kill ?php altogether. So here is what I am seriously suggesting: * The default behavior doesn't change. The parser starts out in HTML mode. * If the CLI sees a .phpc file extension, the parser starts out in PHP mode (no opening ?php is required). It is still possible to shift into HTML mode after that with ?. * If a require/include statement sees a .phpc file extension, the parser starts out in PHP mode. * If mod_php and FPM are able to see the path (I'm honestly not sure if they can or not), they look for .phpc as their indication to start out in PHP mode. If that's not possible then new options are defined to allow Apache to be configured to tell mod_php and/or FPM to do the right thing based on mime types etc. This way .php continues to behave exactly as it does today, and can interoperate smoothly with code that uses .phpc. .phpc can require .php and vice versa. They are friends. Thoughts? -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
That's a good point too. I think this is a better proposal: include_code, require_code, and require_code_once would work just like include, require and require_once, except that the parser would start out in PHP mode. .phpc is then just a convention for naming PHP files that start out with code - a convention that autoloaders should respect, just as they now respect the .php convention. The user asked for the Monkey class, and I see Monkey.phpc is out there; I'll grab that with require_code_once. Putting this decision on the autoloader makes more sense because autoloaders already contain assumptions about file extensions. They have to in order to do their job of translating a class name to a particular path somewhere. Folks who did not care for this functionality could then choose to entirely ignore it. Class library developers who liked it would make autoloaders available that honored it, freeing end-user developers from thinking about it. It becomes self-contained, and people who are writing old-school .php standalone scripts or pages are entirely unaffected. On Sat, Apr 7, 2012 at 9:50 AM, John Bafford dsha...@zort.net wrote: On Apr 7, 2012, at 09:39, Tom Boutell wrote: From the viewpoint of someone writing reusable classes, the need to start with ?php and reprimand anybody who accidentally puts a newline above it is a silly annoyance they don't experience with other tools. That said, you are making valid points, I'm not convinced myself that file extensions necessarily should or could be determined in every context. But it seems the most viable way of addressing the issue - if a viable way even exists. Partly I want to convince myself that this either can or can't ever be improved, and move on either way (: That silly annoyance doesn't seem to bother anyone who writes command line tools, which require the #! line specifying the command interpreter to be the first bytes in the file, with no leading white space whatsoever. Especially on unix systems (but also on the Mac), the file extension does not affirmatively indicate the file type or whether or not it can be executed. Also, from a CLI perspective, you don't want extensions in the names of your scripts, because then it causes problems/confusion/extra work if you later decide to change the language the script is written in. -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
On Sat, Apr 7, 2012 at 10:06 AM, Reindl Harald h.rei...@thelounge.net wrote: would you please leave this world in peace? what do you think happens with hundret thousands of existing include-files out there which are containing only HTML? Nothing happens to them whatsoever. They work exactly the way they did before. I am introducing separate keywords in this proposal precisely to avoid creating problems for you. Please read the email you just replied to. why do you simply not realize that you have way too few knowledge and tchnical education to partly understand the side effects small changes in a general behavior are having *Sigh* See this? http://php.net/manual/en/book.image.php That's my doing, fella. I am the original author of the gd library functions described there and the originator of the PNG file format project as well. You have probably been using my work in your PHP code for years, if you have done much image manipulation with PHP (although there are some fine alternatives as well of course). I also wrote the original WWW FAQ (circa '94) and have helped promote the open web ever since. And do you know how much that matters? Not one little bit. if this proposal stinks, then it should be politely rejected. But not just because somebody can't be civil (: There are no side effects in the new proposal in the latest email you are replying to, at least not that you have accurately identified yet. The .phpc extension has completely vanished from use cases like yours in that proposal. Pay attention to what I wrote and respond thoughtfully. benefit has to be a REAL LARGE ONE for everybody to accept the possible damage - which is not the case here where are your proposals for bash and other unix shells hwo they have to work if there is a whitespace before #!/bin/sh? what have you got as answer there? again: please leave the world in peace with your poorly thought proposals - and yes this is a really polite answer compared with the thoughts running through my mind while reading your stuff -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without ?php at the top
A thoughtful suggestion. But the trouble with a php.ini setting is that you can't tell if it is enabled when writing your class file. That makes it impossible to write portable libraries. The keywords would always be available. And no one has to type them outside of an auto loader (: Sent from my iPhone On Apr 7, 2012, at 11:46 AM, Luke Scott l...@cywh.com wrote: On Apr 7, 2012, at 7:00 AM, Tom Boutell t...@punkave.com wrote: That's a good point too. I think this is a better proposal: include_code, require_code, and require_code_once would work just like include, require and require_once, except that the parser would start out in PHP mode. .phpc is then just a convention for naming PHP files that start out with code - a convention that autoloaders should respect, just as they now respect the .php convention. The user asked for the Monkey class, and I see Monkey.phpc is out there; I'll grab that with require_code_once. Putting this decision on the autoloader makes more sense because autoloaders already contain assumptions about file extensions. They have to in order to do their job of translating a class name to a particular path somewhere. Folks who did not care for this functionality could then choose to entirely ignore it. Class library developers who liked it would make autoloaders available that honored it, freeing end-user developers from thinking about it. It becomes self-contained, and people who are writing old-school .php standalone scripts or pages are entirely unaffected. Tony I think your idea has some merit. If it were up to me I'd remove ?php all together. It really is bad practice to mix HTML into code. But I feel that adding new keywords is not the way to do it. Personally I'd like to see a php.ini setting to disallow the ending ? tag and assume .php files just have PHP code. The starting ?php tag would be optional. White space would be ignored and non-white space characters before ?php would throw a fatal error. Doing it this way would disallow bad practices but still make existing PHP scripts compatible. I think that doing that would be quite reasonable. Those who complain about it likely ignore industry best practices anyway. This option could be turned off by default at first, made default later, and then ? be deprecated all together. So with this option enabled ? is forbidden, ?php is optional, and the text before ?php is handled differently - white spaces ignored, text before throws an error (unless it's a shebang line in cli mode). Hopefully that made sense. Does this sound good to you? I'm sorry you had to endure such a nasty troll. I am so sick of self righteous bullies who think they know it all. Luke On Sat, Apr 7, 2012 at 9:50 AM, John Bafford dsha...@zort.net wrote: On Apr 7, 2012, at 09:39, Tom Boutell wrote: From the viewpoint of someone writing reusable classes, the need to start with ?php and reprimand anybody who accidentally puts a newline above it is a silly annoyance they don't experience with other tools. That said, you are making valid points, I'm not convinced myself that file extensions necessarily should or could be determined in every context. But it seems the most viable way of addressing the issue - if a viable way even exists. Partly I want to convince myself that this either can or can't ever be improved, and move on either way (: That silly annoyance doesn't seem to bother anyone who writes command line tools, which require the #! line specifying the command interpreter to be the first bytes in the file, with no leading white space whatsoever. Especially on unix systems (but also on the Mac), the file extension does not affirmatively indicate the file type or whether or not it can be executed. Also, from a CLI perspective, you don't want extensions in the names of your scripts, because then it causes problems/confusion/extra work if you later decide to change the language the script is written in. -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- 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] PHP class files without ?php at the top
I will. And thanks for your work maintaining gd- I should have mentioned that earlier. Sent from my iPhone On Apr 7, 2012, at 12:47 PM, Pierre Joye pierre@gmail.com wrote: hi Tom, On Sat, Apr 7, 2012 at 3:26 PM, Tom Boutell t...@punkave.com wrote: Now that the flamewar has died down a little I'd like to try to have a civil discussion about this idea - *without* my admittedly inflammatory suggestion to kill ?php altogether. So here is what I am seriously suggesting: Please put that in a RFC. Cheers, -- 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] PHP as a template language
I have to agree with that. Also: does PHP need to be a templating
language anymore, given excellent templating language implementations
in PHP, like Twig?
On Fri, Apr 6, 2012 at 3:05 PM, John Crenshaw johncrens...@priacta.com wrote:
-Original Message-
From: Sébatien Durand [mailto:sun...@live.com]
Sent: Thursday, April 05, 2012 10:55 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP as a template language
IMHO, PHP is a great template language. This is what makes it so simple and
powerful, compared to other web languages.
So far, we have ?php, ?= and various legacy syntaxes like ?.
A suggestion : deprecate these old tags and replace them with a more elegant
and a shorter implementation.
For example : % and %= or {% and {{ ?
What do you think, guys ?
Honestly this is the wrong question. PHP as a template language has much
larger problems than this. The difference between ?php echo and ?= is 7
characters and entirely cosmetic. The difference relative to ?php echo
htmlentities(..., ENT_QUOTES | ENT_HTML5, 'UTF-8'); ? however is 56
characters, security, and encoding bugs.
Proper handling of output escaping is standard in modern template languages.
The question shouldn't be should we add a cooler short tag?. The question
should be What needs to be done to make PHP an industry leader in template
languages again?.
My two cents,
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP as a template language
To tell the truth I'd be more excited by a proposal to kill ?php
entirely, or more realistically, to support an alternate file
extension that doesn't need it. That would be an interesting option
for those who want to put dribs and drabs of PHP sprinkled in HTML
completely behind them.
On Fri, Apr 6, 2012 at 5:19 PM, Tom Boutell t...@punkave.com wrote:
I have to agree with that. Also: does PHP need to be a templating
language anymore, given excellent templating language implementations
in PHP, like Twig?
On Fri, Apr 6, 2012 at 3:05 PM, John Crenshaw johncrens...@priacta.com
wrote:
-Original Message-
From: Sébatien Durand [mailto:sun...@live.com]
Sent: Thursday, April 05, 2012 10:55 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP as a template language
IMHO, PHP is a great template language. This is what makes it so simple and
powerful, compared to other web languages.
So far, we have ?php, ?= and various legacy syntaxes like ?.
A suggestion : deprecate these old tags and replace them with a more
elegant and a shorter implementation.
For example : % and %= or {% and {{ ?
What do you think, guys ?
Honestly this is the wrong question. PHP as a template language has much
larger problems than this. The difference between ?php echo and ?= is 7
characters and entirely cosmetic. The difference relative to ?php echo
htmlentities(..., ENT_QUOTES | ENT_HTML5, 'UTF-8'); ? however is 56
characters, security, and encoding bugs.
Proper handling of output escaping is standard in modern template languages.
The question shouldn't be should we add a cooler short tag?. The question
should be What needs to be done to make PHP an industry leader in template
languages again?.
My two cents,
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP as a template language
Knock it off with the ad-hominem attacks please. It's not change for
the sake of change to propose that PHP move on from needing ?php at
the stop of every class file (and breaking mysteriously in weird
subtle ways if it's missing, due to unneeded whitespace being output)
and recognize that it's a modern language in which you don't mix
unparsed HTML with source code. Especially since I suggested offering
this feature when an alternate file extension is used, to make bc
possible. Your attitude discourages participation.
On Fri, Apr 6, 2012 at 5:25 PM, Reindl Harald h.rei...@thelounge.net wrote:
what exactly is your problem?
having solution searching problem?
what are people like you try to achieve?
what would make you happy in breaking BC?
what would you make happy generate lot of work for others?
what would be better for anybody?
change for the sake of the change is blindly stupid
Am 06.04.2012 23:20, schrieb Tom Boutell:
To tell the truth I'd be more excited by a proposal to kill ?php
entirely, or more realistically, to support an alternate file
extension that doesn't need it. That would be an interesting option
for those who want to put dribs and drabs of PHP sprinkled in HTML
completely behind them.
On Fri, Apr 6, 2012 at 5:19 PM, Tom Boutell t...@punkave.com wrote:
I have to agree with that. Also: does PHP need to be a templating
language anymore, given excellent templating language implementations
in PHP, like Twig?
On Fri, Apr 6, 2012 at 3:05 PM, John Crenshaw johncrens...@priacta.com
wrote:
-Original Message-
From: Sébatien Durand [mailto:sun...@live.com]
Sent: Thursday, April 05, 2012 10:55 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP as a template language
IMHO, PHP is a great template language. This is what makes it so simple
and powerful, compared to other web languages.
So far, we have ?php, ?= and various legacy syntaxes like ?.
A suggestion : deprecate these old tags and replace them with a more
elegant and a shorter implementation.
For example : % and %= or {% and {{ ?
What do you think, guys ?
Honestly this is the wrong question. PHP as a template language has much
larger problems than this. The difference between ?php echo and ?= is 7
characters and entirely cosmetic. The difference relative to ?php echo
htmlentities(..., ENT_QUOTES | ENT_HTML5, 'UTF-8'); ? however is 56
characters, security, and encoding bugs.
Proper handling of output escaping is standard in modern template
languages. The question shouldn't be should we add a cooler short tag?.
The question should be What needs to be done to make PHP an industry
leader in template languages again?.
My two cents,
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/
http://www.thelounge.net/signature.asc.what.htm
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP as a template language
I should have said breaking mysteriously in weird subtle ways if
there are blank lines before ?php.
On Fri, Apr 6, 2012 at 5:30 PM, Tom Boutell t...@punkave.com wrote:
Knock it off with the ad-hominem attacks please. It's not change for
the sake of change to propose that PHP move on from needing ?php at
the stop of every class file (and breaking mysteriously in weird
subtle ways if it's missing, due to unneeded whitespace being output)
and recognize that it's a modern language in which you don't mix
unparsed HTML with source code. Especially since I suggested offering
this feature when an alternate file extension is used, to make bc
possible. Your attitude discourages participation.
On Fri, Apr 6, 2012 at 5:25 PM, Reindl Harald h.rei...@thelounge.net wrote:
what exactly is your problem?
having solution searching problem?
what are people like you try to achieve?
what would make you happy in breaking BC?
what would you make happy generate lot of work for others?
what would be better for anybody?
change for the sake of the change is blindly stupid
Am 06.04.2012 23:20, schrieb Tom Boutell:
To tell the truth I'd be more excited by a proposal to kill ?php
entirely, or more realistically, to support an alternate file
extension that doesn't need it. That would be an interesting option
for those who want to put dribs and drabs of PHP sprinkled in HTML
completely behind them.
On Fri, Apr 6, 2012 at 5:19 PM, Tom Boutell t...@punkave.com wrote:
I have to agree with that. Also: does PHP need to be a templating
language anymore, given excellent templating language implementations
in PHP, like Twig?
On Fri, Apr 6, 2012 at 3:05 PM, John Crenshaw johncrens...@priacta.com
wrote:
-Original Message-
From: Sébatien Durand [mailto:sun...@live.com]
Sent: Thursday, April 05, 2012 10:55 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP as a template language
IMHO, PHP is a great template language. This is what makes it so simple
and powerful, compared to other web languages.
So far, we have ?php, ?= and various legacy syntaxes like ?.
A suggestion : deprecate these old tags and replace them with a more
elegant and a shorter implementation.
For example : % and %= or {% and {{ ?
What do you think, guys ?
Honestly this is the wrong question. PHP as a template language has much
larger problems than this. The difference between ?php echo and ?= is 7
characters and entirely cosmetic. The difference relative to ?php echo
htmlentities(..., ENT_QUOTES | ENT_HTML5, 'UTF-8'); ? however is 56
characters, security, and encoding bugs.
Proper handling of output escaping is standard in modern template
languages. The question shouldn't be should we add a cooler short tag?.
The question should be What needs to be done to make PHP an industry
leader in template languages again?.
My two cents,
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/
http://www.thelounge.net/signature.asc.what.htm
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP as a template language
On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald h.rei...@thelounge.net wrote: what do you expect by propose work for many people Oh I'm sorry, do we need to start every feature suggestion with a description of exactly who will do the work? is it so hard to write It is so embarrassing. Every time I type it a Ruby developer laughs like a hyena. why are you making this whitespaces? fix your editor or get an IDE removing them at save Right, workarounds forever, nothing should be fixed at the source. you are not in the position to dictate how people are working You'll note I acknowledged bc is necessary. But you don't seem to be able to stop yelling anyway. there are differences between projects, classes and rapid-development and thousands of good reasons using input type=text value=?=$myvar? forever while you will not do this in many other projects and lcass files Thousands of good reasons to get pwn3d by XSS attacks! Yay! but you are not realizing that extensuions are meaningless in the real world - you can configure httpd to parse .wtf with PHP That's a valid point. So the cli gets a default behavior based on extension (and options to remap it), and FPM and mod_php get options so you can configure them to do the right thing. This wouldn't be an easy one and perhaps it's not practical, but that's no reason to be venomous. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade cURL extension
I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
Re: [PHP-DEV] Upgrade cURL extension
I do see now that at curl did introduce the @ craziness. So it is unfair of me to single out PHP for introducing it. I'm not sure if the @ syntax is a sneaky feature of the standard C API, but it's definitely a sneaky feature of the command line utility. I did include a comment there when I first opened that bug report, proposing a more appropriate and sustainable interface. Documentation changes would make it possible to avoid the problem by looking carefully for strange gotchas in the fine print - but not to actually submit a value starting with a @, if, y'know, I wanted to do something crazy-nutty like send arbitrary data legal in any other form submission (: Apologies for hijacking the discussion. The '@' business does not come from libcurl. Native C libcurl On Sun, Mar 11, 2012 at 3:38 PM, Pierre Joye pierre@gmail.com wrote: hi Tom, For one, it is mapped to the libcurl constants and behavior. Also this but report contains clear comment about this issue being a documentation problem, contribution welcome :) If you consider it as something that should be changed, then please feel free to add a comment there as well, or a patch :) But that's not really what we discuss here but the new code proposed by Pierrick. Cheers, On Sun, Mar 11, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
Re: [PHP-DEV] Upgrade cURL extension
Sigh, I could have edited that better, but I think the apology came across (: This is still a thing worth fixing. On Sun, Mar 11, 2012 at 6:09 PM, Tom Boutell t...@punkave.com wrote: I do see now that at curl did introduce the @ craziness. So it is unfair of me to single out PHP for introducing it. I'm not sure if the @ syntax is a sneaky feature of the standard C API, but it's definitely a sneaky feature of the command line utility. I did include a comment there when I first opened that bug report, proposing a more appropriate and sustainable interface. Documentation changes would make it possible to avoid the problem by looking carefully for strange gotchas in the fine print - but not to actually submit a value starting with a @, if, y'know, I wanted to do something crazy-nutty like send arbitrary data legal in any other form submission (: Apologies for hijacking the discussion. The '@' business does not come from libcurl. Native C libcurl On Sun, Mar 11, 2012 at 3:38 PM, Pierre Joye pierre@gmail.com wrote: hi Tom, For one, it is mapped to the libcurl constants and behavior. Also this but report contains clear comment about this issue being a documentation problem, contribution welcome :) If you consider it as something that should be changed, then please feel free to add a comment there as well, or a patch :) But that's not really what we discuss here but the new code proposed by Pierrick. Cheers, On Sun, Mar 11, 2012 at 4:22 PM, Tom Boutell t...@punkave.com wrote: I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wanted to make this new version available in PHP5.4 but unfortunately I did finish my work when it was already in RC phase. The question now is should we include this new version in PHP5.4.1 or should we wait for PHP 5.5/6/7 or whatever PHP next will be. There is no feature break (AFAIK) so all the previous code should work as expected. You'll find the list of new features attached and the last code in the trunk branch. Can't you make it also available as pecl extension, which could be built on 5.4? This way people could enjoy the benefits of your work without stable branch being disrupted and BC problems raised. -- 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 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
Re: [PHP-DEV] [RFC] Config setting to force all math operations to pass through BCMath library.
Excellent idea. bcmath is already not the highest performance thing in the world, so adding a function that parses a more reasonable looking expression would not be an unacceptable compromise for most. It also doesn't give you the false impression that since operators do the right thing functions are going to do the right thing too. That's very muddy and confusing. On Tue, Mar 6, 2012 at 5:12 PM, Daniel Macedo admac...@gmail.com wrote: On Tue, Mar 6, 2012 at 22:05, Michael Morris dmgx.mich...@gmail.com wrote: I do use it. It's a pain in the ass to read because you have to LISP nest all the operations. You can't tell me this is easy or intuitive to read... bcadd( bcsub( $bill['penalty'], $bill['rounding'], 2),bcmul( $bill['taxdue'], bcmul( $penalty, $monthsAhead, 2 ), 2 ), 2 ) Compared to $bill['penalty'] - $bill['rounding'] + $bill['taxdue'] * $penalty * $monthsAhead; You can do it, but it's eye bleeding. I agree with you, how about having the bcmath extension support a more general (and even better, non-BC-breaking) function supporting the order of math operations (and maybe even math functions)... Something like a bc(string $operations [, int $scale = 2]) Supporting passing: bc((29.99 + $a) * $b - pow(10, $c) / 2); Came across something like that in the manual: http://php.net/ref.bc#107014 How's that for a quick 'n dirty idea to solve this issue? ~ Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '?=' with PHP5.3.10
I understand the problem with ? and XML, it was just ?= that seemed safe enough to me. Glad it's standard in 5.4. On Mon, Mar 5, 2012 at 6:21 PM, Adam Jon Richardson adamj...@gmail.com wrote: On Mon, Mar 5, 2012 at 6:04 PM, Kris Craig kris.cr...@gmail.com wrote: Personally, I HATE short_open_tab. It has no value-- *except* that, unfortunately, it's still widely used in many apps and even some frameworks TTBOMK. I personally like it and find value in its inclusion :) Adam -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
PHP needs a lot more memory than, say, serving static files. If you used PHP with the worker threaded MPM, and it worked (I haven't heard many stories of people doing this under Linux), wouldn't you just have to dial back the number of threads to pretty much the number of processes you would have allowed under the prefork MPM? The overhead of a process is pretty tiny next to the overhead of a PHP framework. Aren't you therefore just paying a performance and stability price (threadsafe is slower than non-threadsafe, your extensions may or may not play nice...) for not a lot of benefit under Linux when PHP runs under the worker threaded MPM? The best configuration I'm aware of is to run Apache with the worker threaded MPM, and run PHP in a fastcgi pool, so that you can have hundreds of threads serving static and cached content in a hurry, and a smaller pool of more expensive PHP processes. I'm interested to hear if anyone feels there is a superior model for single-server PHP hosting under Linux. (I realize that static files could be pushed out to CDNs and the like but our clients much prefer to have a single straightforward hosting bill to pay, thus the single-server thing for most cases.) On Tue, Feb 28, 2012 at 4:13 AM, jpauli jpa...@php.net wrote: On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 2/27/2012 6:58 AM, jpauli wrote: PHP through mod_php on Linux should compile without ZTS. configure script searches for apxs binary and tries to invoque apxs -q MPM to figure out what MPM has been compiled in Apache for the TS flag to be defined or not (thus, activating PHP ZTS, or not). Right... Mainly on Linux, Apache should have been installed with prefork MPM ans apxs -q should return that, then configure should not define PHP_BUILD_THREAD_SAFE. No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux distros have moved away from it... Sorry but 2.2 defaults to prefork. The new 2.4 platform has introduced loadable MPM, like any other module , thus we cant detect through apxs which MPM is used anymore. For this, we would need to play with httpd -M Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). The only mod_php loadable under any circumstance is TS enabled. Yes, but ZTS has a performance/memory penalty due to globals locks. I would much prefer having a nonZTS PHP together with a non threaded MPM Julien.P If you want php/linux single-child, fastcgi is the only rational approach. I dont know anything about windows, sorry Always threaded. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux distros have moved away from it... Ubuntu starts out with the worker threaded MPM. However when you install the standard PHP package it switches Apache to the prefork MPM. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
In many cases this can be done by refactoring to a method:
public function main()
{
$in = fopen('whatever');
$this-whereTheStuffWent($in);
fclose($in);
}
protected function whereTheStuffWent($in)
{
try {
// Do stuff that might throw an exception
} catch (Exception $e)
{
// Log it or something
}
}
The while loop case in https://bugs.php.net/bug.php?id=36779 could be
dealt with by returning a result from whereTheStuffWent and breaking
out if it's set. Not too bad. finally { } might be a little more
convenient than this I suppose:
$finished = $this-whereTheStuffWent($in);
fclose($in);
if ($finished)
{
break;
}
On Tue, Feb 28, 2012 at 9:25 AM, Paul Dragoonis dragoo...@gmail.com wrote:
Tried to do something the other day and had to write something a bit quirky
tht would have been super clean with a finally block.
+1000
On Tue, Feb 28, 2012 at 2:22 PM, Kiall Mac Innes ki...@managedit.ie wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 2:05 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
This is another feature that we know we can live without
but those familiar with languages that have 'finally' like Java or Python
know that
it is very neat feature to have in some situations.
Basically the code inside 'finally' is guaranteed to run even if there
is a
'return' inside try or catch blocks
in which case the value to be returned is remembered tempraraly, the code
inside finally block executes and then remembered value is returned.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
I did check out the article on using worker thread MPM with PHP on Linux. The basic argument is that since threads can reclaim memory used and then freed by other PHP requests, while processes don't return memory to the OS until they finally exit, there is more memory available. However I doubt that this can be the case when the server is at peak utilization. When things are maxed out you will still have, say, 20 threads hitting PHP scripts that happen to be expensive in terms of memory (let's say 50mb), and that will be roughly all the memory you have to play with in your 1GB system. So you're just as stuck as if you had 20 dedicated fastcgi processes, all maxed out at 50mb already by some previous request. The only win here is that in the average case, you can handle more requests. But you usually can't predict in advance when the worst case will come along. So if you permit that to happen you are risking a slowdown or a meltdown (: For stability a fastcgi pool of the size you know you can handle based on studying your past memory stats still seems to be the way to go. On Tue, Feb 28, 2012 at 10:41 AM, jpauli jpa...@php.net wrote: Actually, the true story for performance is to kill Apache and let Lighttpd or NginX do the job, with a pool of fcgi/fpm PHP processes I'd like to ask you whether it really makes much difference to use Lighttpd or NginX as opposed to Apache with the worker thread MPM, but at that point we are officially way off topic (: I think that in terms of general architecture, and in terms of what to do with PHP, those three options are basically the same option. I haven't studied FPM yet as I haven't felt a need for its advertised advantages over the traditional FastCGI support in the CGI SAPI yet. I will check out the apache worker and PHP article, thanks. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes ki...@managedit.ie wrote:
Yes, You could abstract the try/catch into a new (and un-needed) function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.
'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block
- does it?
I would hope not, since that means something this block of code did
not anticipate at all - another sort of exceptional situation
altogether and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.
Assuming I'm right and 'finally' runs only for normal completion and
for exceptions actually caught by the catch { } block attached to the
same try { }, then my refactoring still behaves exactly like
'finally'.
I am not convinced the function is unnecessary, either. Decomposition
is usually a good idea (:
substitute for a native language construct
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
$log-add(Log::ERROR, Something went wrong, $e);
throw $e;
} finally {
fclose($fh);
}
Thanks,
Kiall
On Tue, Feb 28, 2012 at 4:12 PM, Arvids Godjuks
arvids.godj...@gmail.comwrote:
It's quite hard to think of a compelling example. Usually you just
write the code and realize that Yea, a 'finally' statement would make
a lot of sense here.
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
brainier these days, the last two to me where wtf? does anyone use
that? Where I need them at all?!. It was like that for 3-4 years.
Until I got the code witch actually made an active use of these two
and I understood the purpose.
Same goes to finally. I remember using in JavaScript a few times, helped a
lot.
And it just makes sense to add to complete the try {} catch {} finally
{} template.
My 2 cents.
2012/2/28 Richard Lynch c...@l-i-e.com:
On Tue, February 28, 2012 8:22 am, Kiall Mac Innes wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
+ if ($fh) fclose($fh); //many PHP file errors NULL out the $fh
+ }
- } finally {
- fclose($fh);
- }
Another non-compelling example...
Still not saying finally is a bad idea.
Just want a compelling use case before I would vote...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
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
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibility to add finally to try/catch?
OK, consider my point successfully buried in counterexamples (:
On Tue, Feb 28, 2012 at 12:02 PM, Kiall Mac Innes ki...@managedit.ie wrote:
An an equivalent snippet of ruby..
$ irb
irb(main):001:0 def divide(x, y)
irb(main):002:1 begin
irb(main):003:2* result = x / y
irb(main):004:2 puts result is, result
irb(main):005:2 rescue ZeroDivisionError
irb(main):006:2 puts division by zero!
irb(main):007:2 raise Exception('division by zero')
irb(main):008:2 ensure
irb(main):009:2* puts executing finally clause
irb(main):010:2 end
irb(main):011:1 end
= nil
irb(main):012:0
irb(main):013:0*
irb(main):014:0* divide(2, 1)
result is
2
executing finally clause
= nil
irb(main):015:0
irb(main):016:0* divide(2, 0)
division by zero!
executing finally clause == The interesting part
NoMethodError: undefined method `Exception' for main:Object
from (irb):7:in `divide'
from (irb):16
from :0
irb(main):017:0
irb(main):018:0* divide(2, 1)
executing finally clause
NoMethodError: undefined method `/' for 2:String
from (irb):3:in `divide'
from (irb):18
from :0
Thanks,
Kiall
On Tue, Feb 28, 2012 at 4:54 PM, Kiall Mac Innes ki...@managedit.ie wrote:
On Tue, Feb 28, 2012 at 4:48 PM, Tom Boutell t...@punkave.com wrote:
On Tue, Feb 28, 2012 at 11:32 AM, Kiall Mac Innes ki...@managedit.ie
wrote:
Yes, You could abstract the try/catch into a new (and un-needed)
function
to try and emulate the behavior of finally.. Unless, for example, you
re-throw the exception after logging in the catch.
'finally' doesn't run for stuff that throws an exception not caught in
the try { } block, or an exception thrown again in the catch { } block
- does it?
I would hope not, since that means something this block of code did
not anticipate at all - another sort of exceptional situation
altogether and really should not run any more local code, nothing
until and unless there is a catch block somewhere further up that does
catch that exception.
I would indeed expect the finally to run regardless of what happens in the
catch block.
$ python
def divide(x, y):
... try:
... result = x / y
... except ZeroDivisionError:
... print division by zero!
... raise Exception('division by zero')
... else:
... print result is, result
... finally:
... print executing finally clause
...
divide(2, 1)
result is 2
executing finally clause
divide(2, 0)
division by zero!
executing finally clause == The interesting part
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 6, in divide
Exception: division by zero
divide(2, 1)
executing finally clause
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in divide
TypeError: unsupported operand type(s) for /: 'str' and 'str'
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot build ext/intl on Fedora 15
Bump - this is still a live issue on Ubuntu 11.10, for instance. I just hacked my Ubuntu PHP-from-source installer to touch up the Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job. Which I knew more about autoconf, I'd like to help figure this out properly so everyone doesn't wind up maintaining hacks to compile PHP from source. It discourages a very large community from trying new releases. Is this perhaps because some of the code being included in the PHP build happens to be C++ code? (Not readily apparent from the outside of course.) -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot build ext/intl on Fedora 15
Hmm. Here is my apt-get install line, starting from a stock install of 11.10 in virtualbox: apt-get -y install build-essential apache2 libxml2-dev libcurl4-openssl-dev \ libcurl4-openssl-dev libjpeg-dev libpng-dev libfreetype6-dev libicu-dev \ libmcrypt-dev mysql-server mysql-client libmysqlclient-dev libxslt-dev \ autoconf libltdl-dev Then I pull down 5.3.10, cd to it and run this configure line: './configure' '--enable-fastcgi' '--with-gd' '--with-pdo-mysql' '--with-curl' '--with-mysql' '--with-freetype-dir=/usr' '--with-jpeg-dir=/usr' '--with-mcrypt' '--with-zlib' '--enable-mbstring' '--enable-ftp' '--with-xsl' '--with-openssl' '--with-kerberos' '--enable-exif' '--enable-intl' I then run 'make', which bombs with the error mentioned at link time unless I add -lstdc++ manually. Anyone see a missing package that makes build-essential a little more essential? (: I'll try this again in a fresh install of ubuntu 11.x (shoot, forgot to take a virtualbox snapshot last time). On Sun, Feb 26, 2012 at 2:22 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/26/2012 07:19 PM, Tom Boutell wrote: Bump - this is still a live issue on Ubuntu 11.10, for instance. I just hacked my Ubuntu PHP-from-source installer to touch up the Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job. Which I knew more about autoconf, I'd like to help figure this out properly so everyone doesn't wind up maintaining hacks to compile PHP from source. It discourages a very large community from trying new releases. Is this perhaps because some of the code being included in the PHP build happens to be C++ code? (Not readily apparent from the outside of course.) My dev box is Ubuntu 11.10 and I have no issues building ext/intl. -Rasmus -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
