PHP

Should you ever need to work with XPath extensively, there's XPather for Firefox, that looks quite nice, but unfortunately I couldn't get it to work today, so I had to improvise. Then I stumpled across the very cool feature of xmllint, that lets you browse XML documents like directories.



And to not be completely offtopic, I'll admit that once I got my XPath expressions, I fed them to SimpleXML

(fa@donau):(~/Zend/ZendStudio-5.5.0/bin) $ diff -u ZDE.orig ZDE
--- ZDE.orig 2007-10-23 14:09:19.000000000 +0200
+++ ZDE 2007-10-23 14:03:08.000000000 +0200
@@ -1692,6 +1692,7 @@
fi

debugOut ""
+options="$options -Dawt.toolkit=sun.awt.motif.MToolkit"
unset POSIXLY_CORRECT
if [ $DO_NOT_FORK ]
then

If you get a blank Zend Studio 5.5.0 window...

I've felt the need to both test both the Zend IDE and phpeclipse and so I made a little thing for practice and to fiddle around a bit.

First the Zend IDE made a good first impression, but I gave up soon. I wasn't able to work with a file of just 500 lines because it felt more frozen than sloppy. Default colors for highlighting were quite good and readable, that's a big +1. But it also has problems with a lines with both ' and " in it:
[geshi lang="php]echo 'hello '.$test."\n";[/geshi] is underlined in red and so are the following lines.

I was really surprised by phpeclipse, which I had last tested over a year ago and something wouldn't work and as I was (and still am) quite content with Weaverslave, I didn't check it out lately until now.

For larger projects I'll definitely use phpeclipse from now on - I'm used to using eclipse for Java anyways.

Just a very quick and rudimentary roundup, but imho especially an IDE shouldn't get in the programmer's way and do just what it should be - aid development.

Because I didn't know what to do and I've long searched for something like this, I'll started a quick hack of a directory parsing class, because I don't really find dir()
Output looks like this:



This is a var_dump output of an xDir object:



The code is available under svn.anderiasch.de - any comments welcome.

I'd appreciate any comments if I missed anything with similar behaviour (mainly something like Apache's directory index with a few extras like: "ignore by pattern", level of detail, etc) - perhaps even a PEAR class I overlooked?

I've just installed xdebug and kcachegrind to play around abit, get to know it and try to improve the world's best blogsoftware.

So I installed a fresh copy of serendipity1.0-beta2 on my laptop and started.
Here's the file: cachegrind.out.680592437 and a screenshot

First thing that came to my attention that serendipity_lang_en.inc.php uses 20,3% of the time spent. This can't possibly be and so I first thought of the multibyte stuff - nope. Then I realized that we have a 800 line file with define()s in it for every language. So I moved some of them away and voilá - no more language stuff near the top.

Then I made this script:

which produced following output: cachegrind.out.2897431826

Oh yes, variable assignment is 20x faster and so we could reduce 20% of time spent rendering a page to 1% by rewriting 90% of all files. Perhaps it would be better to store them in the database and just do a global search&replace with LANG_CHARSET becoming $foo['LANG_CHARSET'].

Stay tuned for more interesting profiling stuff, as I could scream for not having tried this before :P Linux on the desktop is at least good for anything but grief :)

Update:
graph with 7 entries on frontpage
screenshot with 7 entries

Update:
serendipity_event_emoticate.php sucks 1-2% performance, could be fixed by using strtr()
serendipity_makeFilename() uses 4% of total time, maybe there's room for improvement.
Other intensive stuff: serendipity_plugin_api::hook_event - 19,85% - 24 calls
functions.inc.php - 5,92% - 1 call
Smarty->plugin_calendar.tpl.php - 6,97% - 1 call
Smarty->index.tpl.php - 3,93% - 1 call
language stuff - still 4% - 1 call
Smarty->_fetch_resource_info - 3,49% - 5 calls
Smarty->entries.tpl.php - 3,16% - 1 call
serendipity_event_s9ymarkup - 2,47% - 14 calls
serendipity_printEntries - 2,20% - 1 call

I just released PEAR_Info 1.6.1.

This was a bugfix release, including:
* 6050
* 6051
* 6732
* 5457

Nothing serious, just a few missing array keys, some E_STRICT/E_NOTICE issues and a bit of polishing the output.

It should still work fine under PEAR 1.3.3 and 1.4.0 - if you find any undiscovered bugs, please use the bugtracker as usual.

Because it was my first release I forgot to mention the bugs in package.xml.
I promise to do that next time.