Slashdot Mirror
PHP 5 Beta 1
Sterling Hughes writes "The PHP development community is proud to announce the release of PHP 5 Beta 1. Downloads are available in both source and binary form (for Windows users). A full list of changes is available in the ChangeLog. Some of the new features include much improved OO support, completely revamped XML support, and the default inclusion of SQLite."
Top Most Bizarre/Disturbing Error Messages
That's right, now you can say class { @P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{q *=2) +=$f=!fork;map{$P=$P[$f^ord[ P.]/&&
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];slee p rand(2)if/\S/;print }
Take a look at the OO changes page. The syntax seems to be converging with Java. I find this amusing in some ways.
The PHP people need to provide ways that people can upgrade the versions of PHP on their system such that they can be reasonably sure that existing users aren't suddenly going to find their sites don't work.
--with-mysql=/path/to/mysql
bundled being the key word
vodka, straight up, thank you!
MySQL isn't bundled with it, but you can easily add it yourself when compiling.
Compiling?
Compiling PHP for Windows requires the Microsoft Visual C++ compiler version 6.0 or later.
The Microsoft Visual C++ optimizing compiler version 6.0 or later is available only from Microsoft as part of Microsoft Visual Studio .NET, which costs $1,079 for one non-academic seat. (Microsoft no longer sells a Visual C++ optimizing compiler separately.)
Some people are bound to bring up the $109 Microsoft Visual C++ Learning Edition, but 1. the EULA attached to its library probably does not permit distribution of generated binaries nor public performance (i.e. use on a public web site) of generated binaries, and 2. because it does not have an optimizer, the speed of generated binaries is closer to that of an interpreted program than to that of a compiled program.
If I had any spare time, I'd fix this by porting the build to MinGW.
Will I retire or break 10K?
The sources can be compiled under Windows and most Unices.
But since Windows doesn't come with a compiler, there is a binary provided for Windows.
So what's your point?
um..
O KIE);
extract($_POST);
extract($_GET);
extract($_CO
?
bananas like monkeys.
Uh, none of those links work, however here is a *recent* comparison of JSP and PHP using several different containers for JSP and PHP. It seems that the server setup has a great deal to do with the speed of the application (duh).
It's interesting that people like to make comparisons to JSP and ASP all the time but don't remark on what platform they run on. Obviously JSP running on tomcat/apache through with mod_jk will be slower than with just plain Resin.
And open should note that a statement like ' Kiss and say goodbye to Java language!!' almost sounds like a troll, when you consider Java is used for a great deal more than web applications, indeed the servlet functionality that JSP relies on is a *very* small portion of the overall tools that Java supplies to developers.
But whatever, use the right tool for the job and try to remember it's technology, not religion. The more options the better IMO.....
1400x1250 in a 640x480 world...
The raw speeds of execution between JSP and PHP may be similar (though I suspect that JSP ends up being much faster once the JIT has kicked in and optimized it, after a few executions). Additionally, there are many different JSP runners (Tomcat is only the reference implementation) and the performance between them can be very large (I recommend the JSP runner by Caucho for performance-critical systems. Besides this, PHP and JSP have a very, very large difference between them:
PHP is usually run as a apache mod or sometimes, as a cgi. Because of this, it cannot store session state or cache inside of its process (since the process is either apache httpd, or the cgi, which terminates at the end of a page run). To get around this, any session variables get serialized and stored to disk at the end of each run, then un-serialized at the beginning of the request. This also means you can have no application-level caches of database information, since there is no place to put these. This is fine for small stateful sites or large stateless sites, but for any serious, large web application that has to maintain a lot of state, this ends up being a big performance disadvantage.
JSP, on the other hand, is run from a servlet runner in a persistent process outside of the apache process. At the beginning of the request httpd makes a socket connection (usually a local unix socket, very fast) to the servlet runner and sends the request there. This is slightly more overhead than everything running in-process, but gives you the huge advantage of being able to cache whatever data you wish to inside the servlet runner's process. This means database lookups can be cached, sessions don't need to be stored in disk, timers for maintenance functions can be set, all within the servlet runner's process. This is great for large, complicated web applications but obviously not great for small, stateless systems, since it requires the overhead of a running JVM at all times you want the application to be available.
Two different types of systems, two different purposes. I happen to use both in my professional web development, but use only java servlets and JSP for serious projects.
Yes yes.. To sooth all the scalp scratching surrounding PHP and FREE (quality) cacheing and encoding look no futher than
.001 slower than zend (faster than PHP Accelerator) and it FREE! Did I mention it works with Zend Optimizer , Zend Encoder and it can also Encode (protect) PHP files?
MMcache - http://www.turcksoft.com/en/e_mmc.htm
It's only a split second
I'm too damn good to you people! ; )
PS: PHP makes programming fun again. Thats why people like to use it. Simple really.
PHP 5 isn't really documented in the PHP 5 manual yet as there are still a few features on the move, and new features to come, but here's a list of PHP 5 related articles and presentations:
Faq: Where can I get more information about PHP5?
Enjoy!
Nah, I reckon one could handle it like this...
/home/myhost/engine.php /res /home/myhost/resources ... or something. I tried it on my server and it seems to work a treat. Once again cheers for the tip
<VirtualHost *>
ServerName www.myhost.com
DocumentRoot
Alias
</VirtualHost>
Hey HeadDown. You're right to take the guy to task, s/he made some crazy comments. But I can at least partially substantiate speed issues. Back in 2000, I worked with Sabeer Bhatia (the Hotmail guy) on a startup called Arzoo. Our product (a Web site similar to epinions) was almost 100% Java, except for a bit of Perl for screen-scraping and searches. But anyway, it was slow -- first with Tomcat, then with JRun. At one point, we gave a private preview to 1,000 journalists. They didn't even visit the site all at once, they trickled in over the course of 3 days or so. Just that was enough to hammer the site. We ended up running cron jobs that would reboot the farm, round-robin, just to solve memory issues and instability.
Now, you can say, well, that was 2000! Try it now! OK. At SST, we have a team that is using Tomcat now. Although the instability is gone, the speed is still an issue -- they have wait screens as you click through the app. My team is working with PHP, and has no wait screens, and no need for them (with 1 exception). Our pages are actually more computationally stressful than the Java stuff, yet PHP is delivering the result to the browser faster.
As a final point, you might suggest that the teams I've worked with do not understand Java or how to run it well. It's no skin off my back if you make that argument -- it's not me doing this stuff, so no blow to my ego. But I think working with 2 different teams over the course of 3 years says something. Perhaps, at the very least, if Java really can handle a bigger load, it is so difficult to tune that mere mortals would do better with PHP.
My Greasemonkey scripts for Digg &
I've been using PHP since the 3.0 days and always loved it's speed in development for small dynamic sites. There is truly nothing simpler (IMO) for small sites. Why on earth did PHP ever become so popular as compared to Perl/CGI? It was the simplicity.
Most people accepted the changes from PHP3 to PHP4 without complaining as PHP4 brought simple session support and other needed features. Thousands of developers wrote scripts for small pages and uses, and those scripts got placed on help sites etc all across the web.
The changes above 4.06 where register_globals got turned off by default and -from a simple beginners point of view- to 4.2 where a stunning array of new arrays were added for sessions, post and get variables. Those things broke almost everybodies scripts, and all those thousands of scripts across the web no longer worked as is. Due to this a lot of ISP's no longer upgraded regularly.
At the same time PHP started jumping on the "web application" gravy train, something for which PHP with it's awkward OO support (no automatic calling of parent constructors etc), lack of stateful session support etc was not designed to do. The makers of Zend decided to go the whole hog and redo OO support, add hundreds of seldom used features but ignore problems with backward compatibility and language simplicity.
Congratulations. Now we have a language that is slowly matching JSP in complexity (as all the 1337 "application developers are saying"), is nowhere nearly as well integrated in in true web applications as JSP is (great, it can support Java classes, how many will simply use Java then?) and is leaving the roots of it's enormous success behind.
Take a lesson from Perl's "failure" in web site popularity. Don't keep on adding features for the love of it.
Instead of ODBC, you'd be better off using the pear/db module as middleware. It supports more databases (mysql, odbc, sqlite, pgsql, etc.) and if it isn't the future standard for database access in PHP, something like it will be.
I've been using PHP's built-in (until now) MySQL functions, because they're faster than pear/db, but this licensing dust-up has convinced me that portability among database vendors is worth a performance hit. And the pear/db module is getting increasing attention and is likely to get faster.
My biggest complaint about PHP is the joke that they pass as "error handling". Yeah great, thanks for exposing all my path names to the outside world if something goes wrong.
Psychic abilities will be added to PHP as of version 6.6.6. From here on you will be able to simply think of the configuration you want and it will be set in php.ini. No longer will you have to read the extremely comprehensive online docs including the manual and especially not the ENTIRE SECTION dedicated to error reporting and logging that tells you extremely clearly how to do what you have just complained is impossible. You would not need to read that page and find the two links within the 1st side that show very clearly information on the display errors, error_log for custom logs and of course log errors to put the errors in the apache logfile.
Your biggest complaint is that you are too lazy to read the manual and you expect everything to be done for you. No programming language can help you with this.