Re: [PHP-DEV] RE: Optimizer discussion
Hi, I'm happy there's some interest in a PHP optimizer :) I agree with Paul that PECL's optimizer duplicates way too much stuff from the Zend engine, which is not practic nor maintainable. (compare for example with the simple constant folder I implemented some years ago: http://web.ist.utl.pt/nuno.lopes/zend_constant_folding.txt). About runkit & friends, I wouldn't worry much about them. If you're running them problably you also don't care about optimizations. If you want to be able to optimize something, you need to remove as many freedom degrees as you can.. Anyway, I don't know how much time you're going to invest in this optimizer, but I'll certainly be more than happy to discuss your ideas. Nuno P.S.: I'll try to meet with Paul in PLDI (in a week) and chat about these kinds of things. Is anyone else comming that wants to join the discussion? - Original Message - From: "Graham Kelly" To: "Paul Biggar" Cc: "PHP Internals" ; "Brian Shire" Sent: Friday, June 05, 2009 1:08 AM Subject: [PHP-DEV] RE: Optimizer discussion Hey, I always love having input. When you said it was vicious I was expecting more, in fact I agree completely with you on a lot of things :-) Anyway, I'm not really sure how much detail you want me to go into (or how much detail people on internals really want me to get into). So, I'll keep it brief for now and can expand on anything. Why not start off with the big stuff, dataflow. I personally believe that working out good data flow for PHP is key to getting good optimizations. But you are right, its a very tricky thing to do and in some cases impossible. Ultimately, I would like to move a lot of the optimizer work more into this direction and use the data flow to build a basic platform for code analysis on which optimizations can be done. For now though, pecl/optimizer is "dumb" about data types :-) The reimplementations of some engine code is messy and work should probably be done to try to remove this where possible. Also, I might be mistaken but the is_numeric_result stuff is partly left over from Turck MMCache which to my understanding this version of pecl/optimizer was based off of. Some of the stuff I was doing with building a function table (for optimizable and some non optimizable functions) was to try and get rid of rudimentary data type detection like this. Actually folding in values from function calls is happening over in the optimize_fcr.c file. I 100% agree with you on the file system functions. They were in there when I started working on the optimizer and I havent really paid much attention to them. The latest CVS version of pecl/optimizer has them at least removed from being candidates for optimization (the code to actually optimize is still there). I'm not sure which optimization you are talking about with the GLOBALS stuff but what your saying makes sense. (Its been awhile since I've looked at the code base myself, I'm just getting back to working on it) As far as my future plans for pecl/optimizer I should really gather up all my ideas and stuff in the next week or so that you or anyone else who is interested can give feedback. At the moment, I'm working on getting the current version to a stable state. I'm also still trying to gauge demand for pecl/optimizer to maybe help figure out direction for the project. (or if there is really any real interest/or use). From: Paul Biggar [paul.big...@gmail.com] Sent: Thursday, June 04, 2009 4:20 PM To: Graham Kelly Cc: PHP Internals; Brian Shire Subject: Optimizer discussion Graham and I are having a brief chat about the work he's going to do on the PECL optimizer. People have asked me to do this on-list (they may have meant the PECL list, but optimizations on PHP seem more relevant here), so here goes. Hi Graham, So the general gist of what I have to say is that dataflow optimizations on PHP are very difficult, and nearly impossible at the function-local level. Loop-invariant hoisting and other redundant expression computation liekwise. If you're planning on working on them, we can go into more detail. I guess the biggest thing is that I'm wondering what your plans are for the PECL optimizer? I've spent about 2 years working on the phc optimizer, (and a bit longer on relevant things) so I hope that my advice will be relevant. I've taken a look through the optimizer a few times over the last while, (and even stolen some ideas from it). Here are my comments on the current code: - There is lots of code which reimplements parts of the engine, for example: ini_bool_decode, optimizer_acosh and friends, optimize_md5, optimize_crc32, optimize_sha1, optimize_class_exists and friends (to a lesser extent). There are also lots of constant foldings, like casts and "0 == false" (etc) in optimize_code_block. I don't understand why there is logic in the code for that, rather than simply executing the opcodes, or const
Re: [PHP-DEV] Notes from the PDM in Chicago
On Fri, Jun 5, 2009 at 23:01, Keisial wrote: > While dealing with the streams interfaces, what about making the api > saner, too? > All those bucket and brigade functions make streams unnecessarily complex > to deal with. > http://www.php.net/manual/en/ref.stream.php I made an honest attempt documenting the stream wrapper (http://php.net/streamwrapper) few weeks ago and was planning on hitting the filter stuff next.. I lost to many braincells in the process and fear going through the filters will leave me with none left.. Help appreciated! :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is there a technical reason
Hi! No, #1 in your list is why people got sick of it. You want to bind the decoupling of two different issues. I do not insist on 1. I'd be ok with not touching short tags but just moving needs short tags anymore, but I could be wrong. We may do it in 2 steps. We might even have The only change I care to see is that Same here. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Notes from the PDM in Chicago
Elizabeth M Smith wrote: > yes Hannes - interfaces for userland implemented streams would help > people trying to figure out if they have all the methods they need for a > particular stream type (SeekableStream et al) - this would be backward > compat (you wouldn't HAVE to implement the interfaces IIRC, at least not > right away) but would help things along - Sara had the general ideas for > how this would be done. > > rough draft sounds good - code? > > Thanks > Elizabeth Smith > While dealing with the streams interfaces, what about making the api saner, too? All those bucket and brigade functions make streams unnecessarily complex to deal with. http://www.php.net/manual/en/ref.stream.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Makefile.frag on windows?
> > How does one do the equivalent of Makefile.frag for the windows build? > AFAIK only config.w32 files are used under Windows and they are used only when buildconf.js creates configure.js in the root directory of the sources. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is there a technical reason
On 6/5/09 2:17 PM, Stanislav Malyshev wrote: Hi! So it feels like decoupling My proposal would be very simple: 1. short_open_tag setting removed in 6, And while few want to talk about short tags (again), it's worth noting that a discussion specific to decoupling really hasn't taken place except for silence and a few "yeah, that might be alright... sometime" I was kind of under impression I talked about it so much at the time that everybody's sick of it, but maybe I'm wrong :) No, #1 in your list is why people got sick of it. You want to bind the decoupling of two different issues. The only change I care to see is that let me clean up templates in so many places. As it is, I can't use that in any distributed project because "short tags" may be disabled. Leave short tags forever for all I care. Probably more work to remove them than it is to leave them in. -- Brian. http://brian.moonspot.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is there a technical reason
Hi! So it feels like decoupling Rasmus or Stas, could you please propose exactly how this might happen? My proposal would be very simple: 1. short_open_tag setting removed in 6, under any circumstances. 2. And while few want to talk about short tags (again), it's worth noting that a discussion specific to decoupling really hasn't taken place except for silence and a few "yeah, that might be alright... sometime" I was kind of under impression I talked about it so much at the time that everybody's sick of it, but maybe I'm wrong :) -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is there a technical reason
On Jun 5, 2009, at 12:53 AM, Rasmus Lerdorf wrote: Hannes Magnusson wrote: On Fri, Jun 5, 2009 at 07:47, Rasmus Lerdorf wrote: Nobody is going to pass a PHP script through an XML parser, and PHP itself will never be well-formed, so that is a lost cause. We'd have to start tossing CDATA blocks and write code like: if( 2 < 3 ) echo "2 is less than 3"; No you don't. & and < are perfectly legal in PIs And that just isn't going to happen. The only valid argument against short_tags itself is that it clashes with named PI tags and does not have that same problem. The point still stands. If you are trying to parse PHP with an XML parser, you are doing it wrong. I have absolutely no problems annoying the one or two pedantic people who care about this for the benefit of thousands who don't. The RFC was marked declined due to repeated discussions and lack of change, but declined without much fanfare or official yay or nay discussion aside from a mention in a recent related thread, IRC, and CVS. So it feels like decoupling Rasmus or Stas, could you please propose exactly how this might happen? Like when, and if the fate of short_open_tag would be affected (which is never deprecate nor disable by default). And while few want to talk about short tags (again), it's worth noting that a discussion specific to decoupling really hasn't taken place except for silence and a few "yeah, that might be alright... sometime" Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compiling 5.3 Snap on OS.X (embed & static/shared compile issue)
My issue: ld: duplicate symbol _spl_ce_SplDoublyLinkedList in ext/spl/.libs/ spl_dllist.o and ext/spl/.libs/php_spl.o collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 I can confirm the exact same error after "./configure --enable-embed" but know nothing beyond that. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compiling 5.3 Snap on OS.X (embed & static/shared compile issue)
Hi Ralph, On Fri, Jun 5, 2009 at 5:59 PM, Ralph Schindler wrote: > Similarly described in this bug: > > http://bugs.php.net/bug.php?id=42106 You might also find this relevant: http://bugs.php.net/bug.php?id=44462 Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Optimizer discussion
Hi Graham, On Fri, Jun 5, 2009 at 12:03 PM, Paul Biggar wrote: >> Why not start off with the big stuff, dataflow. I personally believe that >> working out good data flow for PHP is key to getting good optimizations. But >> you are right, its a very tricky thing to do and in some cases impossible. >> Ultimately, I would like to move a lot of the optimizer work more into this >> direction and use the data flow to build a basic platform for code analysis >> on which optimizations can be done. For now though, pecl/optimizer is "dumb" >> about data types :-) > > > And now the hard stuff. To avoid me repeating myself, let me just pimp > my Tech Talk. Have a look at > http://www.youtube.com/watch?v=kKySEUrP7LA from about the 30:45 mark > until just before the 47:00 mark (slides at > https://www.cs.tcd.ie/~pbiggar/paul_biggar_google_18_mar_2009_notes.pdf). > That highlights most of the problems, and vaguely hints at their > solution. We can go into much greater detail on the solutions after. Based on the fact that you want to do dataflow, I wonder if its a good idea to think about co-opting the phc optimizer to perform analysis on bytecode. To my mind this seems much easier than re-implementing from scratch. As I mentioned before, this incorporates about 2 years of work (much of it research of course, so it might not take as long to replicate). This would mean you could go straight to performing analyses (though there will no doubt be work required on the optimizer itself). Technically speaking, this isn't a big problem. We'd probably need to change the phc MIR to mirror the bytecode (no harm anyway in terms of correctness), and have a bytecode-reader and -writer (though this needn't involve serializing - likely a small interface instead). Politically, I assume it won't be a problem either, since its in PECL. Thoughts? Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compiling 5.3 Snap on OS.X (embed & static/shared compile issue)
I attempted to compile the 5.3 snap for the cli and embed sapi (Shared) and run into what appears to be an issue with trying to link duplicated symbols. The problem appears to go away if I attempt to compile the embed sapi statically. Other report: http://marc.info/?l=php-install&m=120475189522623&w=2 Similarly described in this bug: http://bugs.php.net/bug.php?id=42106 My issue: ld: duplicate symbol _spl_ce_SplDoublyLinkedList in ext/spl/.libs/spl_dllist.o and ext/spl/.libs/php_spl.o collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 Is this an issue? should i file a bug report? I am using the stock gcc provided with xcode on os.x 10.5, no custom CFLAGS. I imagine the problem goes away when statically compiling b/c I see this line where the original error is produced: "copying selected object files to avoid basename conflicts..." Thanks, Ralph Schindler -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/phar/phar pharcommand.inc
Hannes Magnusson wrote: > On Thu, Jun 4, 2009 at 14:31, Hannes Magnusson wrote: > >> On Thu, Jun 4, 2009 at 14:21, Hannes Magnusson wrote: >> >>> bjori Thu Jun 4 12:21:59 2009 UTC >>> >>> Modified files: >>>/php-src/ext/phar/phar pharcommand.inc >>> Log: >>> Fixed creating directory structure when extracting phars >>> >> So I am a bit confused here, are there tests for these PHP files? >> Should there be? >> > > As it turns out, it would actually have been simpler to simply use the > ext itself. > > Is there any reason why that app doesn't use ext/phar? > More importantly, should it be documented with the ext/phar docs? Hi Hannes, In principle, I agree with everything. In practice, I've not been the maintainer of phar.phar, this is Marcus's baby, so I am not familiar with its innards. I have used it in the past month to debug some issues in some generated phars, however, so I do think it's useful. What would be nice, of course, is if it were part of ext/reflection as you say, but this is a post-5.3 issue. In terms of documentation, this is also true, and when I wrote the docs for ext/phar, it didn't even occur to me that this should be documented. As I said before, I have very limited time, is there anyone willing to document this thing? I think it would simply be a question of documenting the commands available. I may have time to do the tests, but that is also tenuous, so if there is a testfester who would like to tackle these, it would be greatly appreciated. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test for edge cases with __get and property access flags
Here's that test. I don't have commit rights to that area of CVS so
someone will need to do it for me.
John Mertic
jmer...@php.net
On 6/5/09 5:58 AM, Stan Vassilev wrote:
3. When the caller tries to retrieve $object->foo, and foo is a
private/protected member the caller has no access to, instead of an error, __get
is called.
I'm not very sure the current behavior on item 3 is the best one (maybe
error should be thrown regardless?), but freezing on either would be better
than leaving it undefined :)
I always thought that this is the supposed behaviour. I believe I even
relied on it in one of my projects
Hi,
If the community wants it like it is, then I'm just fine with that: as long as
the test is committed, so that it doesn't change overnight. Any volunteers :)?
Regards,
Stan Vassilev
--TEST--
Test for __get() and __set() being able to access private/protected members
--FILE--
$name;
}
function __set($name, $val) {
$this->$name = $val;
}
}
$foo = new Test();
$foo->x = 'foo';
$foo->y = 'bar';
var_dump($foo->x);
var_dump($foo->y);
?>
===DONE===
--EXPECT--
string(3) "foo"
string(3) "bar"
===DONE===
--UEXPECT--
unicode(3) "foo"
unicode(3) "bar"
===DONE===
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is there a technical reason
Hi,
Plain
readfile('file.xml');
From what I know, in the future versions of PHP short tags are going to be
disabled by default. Considering the conflicts with XML syntax, that's
understandable.
// no conflict
'?>
// conflict with full PHP tags
' ?>
// conflict with full PHP tags
*/ ?>
I think these four examples should render any argument containing "XML" and
"PHP" in the same sentence invalid.
My suggestion is, follow your own notes: "Leave short tags alone - never
talk about it again" (http://wiki.php.net/summits/pdmnotesmay09).
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test for edge cases with __get and property access flags
I thought this was the expected behaviour as well and I am quite sure that I've used it in an experiment (all class members private and _get() output escapes them) that failed pretty miserably. But I did think this was the expected behavior. Perhaps it ought to throw an E_STRICT? On Fri, Jun 5, 2009 at 8:58 AM, Stan Vassilev wrote: > > >3. When the caller tries to retrieve $object->foo, and foo is a > private/protected member the caller has no access to, instead of an error, > __get is called. > >I'm not very sure the current behavior on item 3 is the best one (maybe > error should be thrown regardless?), but freezing on either would be better > than leaving it undefined :) > > > I always thought that this is the supposed behaviour. I believe I even > relied on it in one of my projects > > > Hi, > > If the community wants it like it is, then I'm just fine with that: as long > as the test is committed, so that it doesn't change overnight. Any > volunteers :)? > > Regards, > Stan Vassilev
Re: [PHP-DEV] Test for edge cases with __get and property access flags
3. When the caller tries to retrieve $object->foo, and foo is a private/protected member the caller has no access to, instead of an error, __get is called. I'm not very sure the current behavior on item 3 is the best one (maybe error should be thrown regardless?), but freezing on either would be better than leaving it undefined :) I always thought that this is the supposed behaviour. I believe I even relied on it in one of my projects Hi, If the community wants it like it is, then I'm just fine with that: as long as the test is committed, so that it doesn't change overnight. Any volunteers :)? Regards, Stan Vassilev
[PHP-DEV] Re: Optimizer discussion
Hi Graham, Simple things first: On Fri, Jun 5, 2009 at 1:08 AM, Graham Kelly wrote: > I'm not sure which optimization you are talking about with the GLOBALS stuff > but what your saying makes sense. (Its been awhile since I've looked at the > code base myself, I'm just getting back to working on it) I copied that comment straight from the source, but I can't find it now that I went looking for it. No matter. > Why not start off with the big stuff, dataflow. I personally believe that > working out good data flow for PHP is key to getting good optimizations. But > you are right, its a very tricky thing to do and in some cases impossible. > Ultimately, I would like to move a lot of the optimizer work more into this > direction and use the data flow to build a basic platform for code analysis > on which optimizations can be done. For now though, pecl/optimizer is "dumb" > about data types :-) And now the hard stuff. To avoid me repeating myself, let me just pimp my Tech Talk. Have a look at http://www.youtube.com/watch?v=kKySEUrP7LA from about the 30:45 mark until just before the 47:00 mark (slides at https://www.cs.tcd.ie/~pbiggar/paul_biggar_google_18_mar_2009_notes.pdf). That highlights most of the problems, and vaguely hints at their solution. We can go into much greater detail on the solutions after. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is there a technical reason
Hannes Magnusson wrote: > On Fri, Jun 5, 2009 at 07:47, Rasmus Lerdorf wrote: >> Nobody is going to pass a PHP script through an XML parser, and PHP >> itself will never be well-formed, so that is a lost cause. We'd have to >> start tossing CDATA blocks and write code like: >> >> if( 2 < 3 ) echo "2 is less than 3"; > > No you don't. & and < are perfectly legal in PIs > > >> And that just isn't going to happen. The only valid argument against >> short_tags itself is that it clashes with named PI tags and > have that same problem. > > > 4]NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] > | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | > [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] > | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x1-#xE] The point still stands. If you are trying to parse PHP with an XML parser, you are doing it wrong. I have absolutely no problems annoying the one or two pedantic people who care about this for the benefit of thousands who don't. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is there a technical reason
On Fri, Jun 5, 2009 at 07:47, Rasmus Lerdorf wrote: > Nobody is going to pass a PHP script through an XML parser, and PHP > itself will never be well-formed, so that is a lost cause. We'd have to > start tossing CDATA blocks and write code like: > > if( 2 < 3 ) echo "2 is less than 3"; No you don't. & and < are perfectly legal in PIs > And that just isn't going to happen. The only valid argument against > short_tags itself is that it clashes with named PI tags and have that same problem. http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/phar/phar pharcommand.inc
On Thu, Jun 4, 2009 at 14:31, Hannes Magnusson wrote: > On Thu, Jun 4, 2009 at 14:21, Hannes Magnusson wrote: >> bjori Thu Jun 4 12:21:59 2009 UTC >> >> Modified files: >> /php-src/ext/phar/phar pharcommand.inc >> Log: >> Fixed creating directory structure when extracting phars > > So I am a bit confused here, are there tests for these PHP files? > Should there be? As it turns out, it would actually have been simpler to simply use the ext itself. Is there any reason why that app doesn't use ext/phar? More importantly, should it be documented with the ext/phar docs? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
