[PHP-DEV] removing some cruft
Removing some cruft from php I'm thinking that the logo should be optional --disable-logo PHPE9568F34-D428-11d2-A769-00AA001ACF42 http://www.phpsadness.com/ via combinator http://news.ycombinator.com/item?id=2591845 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing some cruft
2011/5/28 marius adrian popa map...@gmail.com: Removing some cruft from php I'm thinking that the logo should be optional --disable-logo PHPE9568F34-D428-11d2-A769-00AA001ACF42 expose_php = Off? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing some cruft
On Sat, May 28, 2011 at 06:05, Kalle Sommer Nielsen ka...@php.net wrote: expose_php = Off? I think what he and others mean is that they want the option to leave the logo, credits, et cetera, completely out of the build at compile time. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: What's up with Quercus?
I sent this message to the php-general list, but haven't gotten any replies. Looking at the archives for the two lists, I realized that I'm probably much more likely to get informed responses from this list than the general list: Although I've been mostly using Java and Ruby in my professional software development work for the past decade or so, in the past two or three years I've started to do more and more PHP. I originally started using PHP because I needed to set-up and customize Drupal for a project. Although as a programmer I've come to feel comfortable writing PHP code, I still don't feel like I have a good sense of where PHP is going as a platform and what's it's future is. As the Drupal site has continued to grow both in terms of features and usage, it's become clear that this is something that I need to research and educate myself about. That led me to give a closer look at Quercus, the implementation of PHP 5 that runs on top of the JVM. I'd already heard about it somewhere along the line, but it's only in the past couple of weeks that I've actually pulled it down, read through the documentation and some of the source and tried it out. So far I'm pretty impressed and enthusiastic about it. The cancellation of PHP 6 combined with the steady trickle of PHP-related bugs and security vulnerabilities that have become public over the past few years had made me very nervous about the future of the platform. Having an open-source implementation of PHP that runs on the JVM, which is like the gold standard for server application performance and reliability, is reassuring. The fact that it makes it easy and fast to use the huge library of Java frameworks out there in your PHP applications doesn't hurt either. Although I've had great results so far in my experiments with Quercus, I'm curious to hear about other PHP developers' experiences with it. Even though it seems like a significant number of people are using it for production applications, I'm curious why it's adoption isn't even higher than it is? Given the difficulties of writing a Virtual Machine, it seems like leveraging the JVM is a no brainer. Is there some technical drawback that I'm unaware of or is it just a case of inertia? Thanks. -- Arnold -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
From my experience with Java: * It's not that easy to properly configure JVM for production use. * If you'll do it wrong and there is a memory leak it can hang the server. At least it was the case when using SOLR. I sent this message to the php-general list, but haven't gotten any replies. Looking at the archives for the two lists, I realized that I'm probably much more likely to get informed responses from this list than the general list: Although I've been mostly using Java and Ruby in my professional software development work for the past decade or so, in the past two or three years I've started to do more and more PHP. I originally started using PHP because I needed to set-up and customize Drupal for a project. Although as a programmer I've come to feel comfortable writing PHP code, I still don't feel like I have a good sense of where PHP is going as a platform and what's it's future is. As the Drupal site has continued to grow both in terms of features and usage, it's become clear that this is something that I need to research and educate myself about. That led me to give a closer look at Quercus, the implementation of PHP 5 that runs on top of the JVM. I'd already heard about it somewhere along the line, but it's only in the past couple of weeks that I've actually pulled it down, read through the documentation and some of the source and tried it out. So far I'm pretty impressed and enthusiastic about it. The cancellation of PHP 6 combined with the steady trickle of PHP-related bugs and security vulnerabilities that have become public over the past few years had made me very nervous about the future of the platform. Having an open-source implementation of PHP that runs on the JVM, which is like the gold standard for server application performance and reliability, is reassuring. The fact that it makes it easy and fast to use the huge library of Java frameworks out there in your PHP applications doesn't hurt either. Although I've had great results so far in my experiments with Quercus, I'm curious to hear about other PHP developers' experiences with it. Even though it seems like a significant number of people are using it for production applications, I'm curious why it's adoption isn't even higher than it is? Given the difficulties of writing a Virtual Machine, it seems like leveraging the JVM is a no brainer. Is there some technical drawback that I'm unaware of or is it just a case of inertia? Thanks. -- Arnold -- Alex Makarov http://rmcreative.ru/
Re: [PHP-DEV] Fwd: What's up with Quercus?
I sent this message to the php-general list, but haven't gotten any replies. Looking at the archives for the two lists, I realized that I'm probably much more likely to get informed responses from this list than the general list: Probably a Caucho list would better. php-internals is primarily focused on C PHP implementation (sometimes called mod_php, but can be run well in other modes and other APIs now) of PHP. ... and enthusiastic about it. The cancellation of PHP 6 combined with the steady trickle of PHP-related bugs and security vulnerabilities that have become public over the past few years had made me very nervous about the future of the platform. Having an open-source ... That is actually quite normal. Bug reports, some of which are security related, and then the release of new point releases are part of the normal heartbeat of software development. When the heart stops beating, the product is dead. And so far as PHP6... a lot of the features that were supposed to be in PHP6 actually ended up in 5.3. So rather than canceled, no longer necessary might be a better description of what happened to PHP6. Although I've had great results so far in my experiments with Quercus, I'm curious to hear about other PHP developers' experiences ... Since Quercus is basically the same speed as PHP+APC, but doesn't support all of the extensions that PHP5.3, it has no interest for me. It probably is only useful for those with some Java libraries they have to access from PHP5. But the popular solution to that, these days is use some sort of REST or Thrift interface to the Java library. Plus, Cauch doesn't state which version of PHP5 they are compatible with. PHP5.2? PHP5.3? There are new language features in 5.3. Also, HipHop is getting pretty good too. Since HipHop is faster than PHP+APC, it would be faster than Quercus as well. Drupal works quite well under HipHop, apparently (see http://php.webtutor.pl/en/2011/05/17/drupal-hiphop-for-php-vs-apc-benchmark/). Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
On Sat, 28 May 2011 18:46:52 +0100, Arnold Hesnod ahes...@mindvox.com wrote: I sent this message to the php-general list, but haven't gotten any replies. Looking at the archives for the two lists, I realized that I'm probably much more likely to get informed responses from this list than the general list: I doubt it. This is the same list that doesn't see the point of annotations or wants them pushed to documentation blocks. Since annotations have been a central part of the last 100 or so JSRs and I've only seen one or two informed objections, it's fairly obvious the list has had very little experience with Java. [...] The cancellation of PHP 6 combined with the steady trickle of PHP-related bugs and security vulnerabilities that have become public over the past few years had made me very nervous about the future of the platform. Having an open-source implementation of PHP that runs on the JVM, which is like the gold standard for server application performance and reliability, is reassuring. The fact that it makes it easy and fast to use the huge library of Java frameworks out there in your PHP applications doesn't hurt either. The security vulnerabilities may have been overstated. It's true there are plenty of ways to crash PHP, but this is mostly by running specific scripts. It's not very frequently that remotely exploitable bugs are found. Although I've had great results so far in my experiments with Quercus, I'm curious to hear about other PHP developers' experiences with it. Even though it seems like a significant number of people are using it for production applications, I'm curious why it's adoption isn't even higher than it is? Given the difficulties of writing a Virtual Machine, it seems like leveraging the JVM is a no brainer. Is there some technical drawback that I'm unaware of or is it just a case of inertia? I've heard about Quercus for several years but never really tried it. Recently, I tried to use it as a view engine for Spring Surf web scripts, but then got distracted with something else and abandoned it. Anyway, I decided to give it another try and attempted to run a PHP application I wrote under Quercus. This is my experience: The first thing I noticed is the Maven repository ran by the company -- http://caucho.com/m2/ -- had an artifact named resin-quercus. However, this seems to a fairly old version (3.2.1) from 2008. I then checked the site and the quercus specific pages always referred to 3.x versions. The resin artifact contained more up-to-date versions, however, it's a complete Java Application Server. So Quercus, as a standalone product, seems to be discouraged. In order to use Quercus, they try to push their crippleware open-source application server, in the hope you'll buy their paid product. Nothing wrong with that, it's certainly preferable to a full closed-source strategy, but you have to wonder whether at some point further development in Quercus (or part of it) may move to the paid version. FUD apart, I continued and added the full resin 4.0.17 artifact as a runtime dependency, added the servlet to the descriptor and tried to run my PHP application. I immediately hit two problems: * htmlentities() will only take 3 arguments, not 4. * error_get_last() doesn't exist. I then tried to work around this to get something vaguely functional, but then hit what seems to a bug in the postgresql module implementation -- pg_query_params will return false in non-select statements, even though there's no error (see PostgresModule.executeInternal). This took me stepping through the source code to realize because there was absolutely no log statement and, of course, pg_last_error would give nothing. Then I had another problem, which I don't recall, at which point I gave up. My conclusion is that Quercus is far from being a drop-in replacement for PHP. If you're writing an application from scratch, it might be a good option (I can't tell). It is probably a very good option if you need interaction with Java and for some reason exposing it with a web service is not an option. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
Hi! annotations have been a central part of the last 100 or so JSRs and I've only seen one or two informed objections, it's fairly obvious the list has had very little experience with Java. Maybe having experience with Java is exactly the reason why some people are reluctant to make PHP more like Java... Just saying ;) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
Martin Scotta On Sat, May 28, 2011 at 11:31 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! annotations have been a central part of the last 100 or so JSRs and I've only seen one or two informed objections, it's fairly obvious the list has had very little experience with Java. Maybe having experience with Java is exactly the reason why some people are reluctant to make PHP more like Java... Just saying ;) yes, Java has kind-of well-defined standard for building web applications. It's a shame that PHP does not. Of couse you can have all that with PHP, but not out of the box. Probably that's why there are tons of PHP frameworks, but almost no library. I really dont like to move away from PHP, but compared to others... it's just a template language with steroids. and please dont get me wrong, I love PHP, it's is still my favourite but... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
Hi, And so far as PHP6... a lot of the features that were supposed to be in PHP6 actually ended up in 5.3. So rather than canceled, no longer necessary might be a better description of what happened to PHP6. With the loss of Unicode (which now lacks even an implementation plan) no longer necessary seems wildly inaccurate. I've no wish to pull this thread off topic, but far too many developers and teams were anticipating that feature to let that statement slide uncontested. paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
On May 28, 2011, at 10:55 PM, Martin Scotta wrote: I really dont like to move away from PHP, but compared to others... it's just a template language with steroids. and please dont get me wrong, I love PHP, it's is still my favourite but... This has been exactly my experience when trying to use PHP in any meaningful way. For example, trying to use PHP as a network server: - I immediately had to write an extension to give me access to several missing APIs (clock_gettime() and a number of ncurses functions not implemented in the ncurses extension). - In order to use stream_select() with both network sockets and STDIN, I had to merge socket_select() with stream_select() in my extension, as in 5.3 stream_select() doesn't preserve socket array keys (this was fixed in 5.4) - To make use of pack() and unpack() for packet management, I had to reimplement them so as not to throw notices willy-nilly when I got bad packets. (Adding format specifiers that could handle useful data types not in the original API was just a bonus.) - In general, I have to tiptoe all over everything to avoid getting useless notices/warnings for expected error conditions (such as SIGPIPE on dying sockets, passing zero sockets to stream_select(), trying to fopen() a nonexistant file, and so forth). - No threading support. - No preprocessor. define() makes up for only some of it, closures make up for some more, but still not enough. There are no mature opensource preprocessor implementations for PHP that I can find (just betas of various sorts), and both GCC's and Clang's CPPs break on here/nowdocs. More generic preprocessors (like m4) tend to have learning curves or problems of their own. - (Almost) everything here: http://www.phpsadness.com/ - No Unicode. If there is any direction for PHP 6, I'd like to see that direction be dealing with problems like these. PHP has been used more and more as a general-purpose language, when it wasn't designed to be. Addressing that would solve a lot of core problems. And yes, it does mean an engine rewrite. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
