Having come across mentions of it and seen pages of Knuth’s work, I became curious about literate programming. For those who have not come across it before, literate programming (LP) is an approach that mixes code in with extensive documentation to create something that is human readable and similar to a book.
So far I’ve encountered no instances of people using literate programming when writing PHP. Do you know of any?
Well, Happy Christmas everyone! I wasn’t intending to post today, but (a) things are slack here, and (b) a client contacted me to say his website wasn’t working. He was getting the error message:
bc. Fatal error: session_register(): Failed to initialize storage module: user (path: /tmp) in /path/to/file.php on line XX
As he hosts with either of the two companies I deal with, I told him to contact his hosting company as it looked like a server problem.
Then I checked one of my sites - I had the same problem. Mmm. Thoughts flashed through my mind - was this an evil PHP bug, dedicated to wipe every site off the Internet on Christmas day? Had I done something stupid?
A “search on Google”:http://www.google.co.uk/search?q=Fatal+error%3A+session_register()%3A+Failed+to+initialize+storage+module%3A+user+(path%3A+%2Ftmp)+in turned up a few results, most illuminatingly “this PHP bug report”:http://bugs.php.net/bug.php?id=25876. I don’t remember having set a session.save_path anywhere, so I’m going to live with this as a random happening for the time being.
I’ll keep you informed if more information turns up.
Having put off writing documentation for Image_Transform for too long (which I realised today when I came to write a program and couldn’t remember the API) I’ve been looking around at visual Docbook editors available for free. Here’s two I’ve found so far:
* “Morphon”:http://www.morphon.com/xmleditor/index.shtml
* “XMLmind Standard Edition”:http://www.xmlmind.com/xmleditor/stdedition.html
Both edit their own DocBook samples perfectly; neither will open PEAR’s documentation without errors.
Morphon says:
@FatalError at file file://localhost/C:/code/peardoc/en/preface.xml[line 18,column 27]: The entity “url.docbook.xml” was referenced, but not declared.@
XMLmind won’t even open the file, kicking up the error:
@parse error in “file:/C:/code/peardoc/en/preface.xml”, linke 18, column 9: reference to undefined entity “url.docbook.xml”@
How do I get these entities to be referenced? Obviously I’m missing something, but I’ve found nothing I understand in the documentation to fix the problem.
With “people requesting”:http://www.procata.com/blog/archives/2004/07/29/goto-in-php/ @goto:@ statements for PHP, I thought it time I revealed the feature I’m wishing for
*I* want PHP to support…
p>. #ifdef … #endif preprocessor directives!
Why? Good question, let me explain my thinking…
I write a fair bit of debugging code in recent projects. Usually an @if (defined(’DEBUG’)@ statement containing @print@ statements; sometimes calls to a logging object/function (inside or without the @if@). None of which is needed when the code is in production.
Therefore if PHP included a preprocessor to remove these entries I could have faster execution, and save me having to run my files through a simple parser/regexp to remove such entries (OK, not done this yet, but I’ve been thinking of it).
I’m working on parsing HTML at present using XML_HTMLSax; as usual I need to skip a large number of the @case@ statements if a variable is not true. Is there a legal alternative to the following?
bc. $foo = ‘baz’;
switch($foo){
case ‘bar’:
print ‘BAA’;
break;
if ($varisset) {
case ‘moo’:
print ‘ANIMAL!’;
break;
case ‘brrrrr’:
print ‘COLD?’;
break;
}
} // switch
“Jeremy Z”:http://jeremy.zawodny.com/blog: “Database Abstraction Layers Must Die!”:http://jeremy.zawodny.com/blog/archives/002194.html
Apart from the fact Jeremy seems to be a mouthpiece for MySQL (oh wait, evangelist is the right word isn’t it?) and should therefore be in favour of programs that only work with one database (which would have to be the one with 90% market share), I think he is wrong for the majority of PHP users. These are a few reasons:
# Most PHP sites are not using relational databases as they should be. Rather, they are using the database as a convenient way to store data. News items, for example, could just as easily be stored in text files. Heck, the majority of an application such as “phpBB”:http://www.phpbb.com/ doesn’t _need_ the relational capabilities of a database. They’re just really convenient stores - they abstract the bother of extracting one row from a text file, and hide the problems of file locking and permissions.
# For the majority of scripts, portability is important, more so than performance. You get more users, more customers, if your script will work with their database. While the majority use MySQL, so you would lose a very small percentage of the market I like to support choice (and think how unique your product is: ‘WOW, a PHP script that supports _my_ database and doesn’t force me to use MySQL!).
# Increased speed of development. Pear’s “DB_DataObject”:http://pear.php.net/manual/en/package.database.db-dataobject.php speeds up development (when having to consider portability) and prevents me worrying about complex SQL queries not being portable. OK, I’m struggling to get my head around it, but everything has a learning curve I have always used PEAR’s “DB”:http://pear.php.net/manual/en/package.database.php abstraction layer because it gives me one API to remember instead of 3. It may be a large amount of code (and I look forward to the day PEAR.php itself is slimmed down - I *hate* PEAR’s error handling) but saves me time.
“Jim’s take”:http://revjim.net/comments/10079/ on this makes for a good read.
Oh, and the “template rant”:http://www.sitepoint.com/forums/showpost.php?p=498687&postcount=15 Jeremy linked to, he might be interested to know that the author appears to have moved away from PHP. Not really a good example of what the rest of us should be following eh?
Does anyone know of code to parse an HTML table into a PHP array? There’s plenty taking a PHP array and converting it to HTML, but Google didn’t turn up anything written to go the other way.
This seems to be one area without consistent development.
I’m trying to add plugin support to FormProcessor, so that Javascript validation etc doesn’t have to be added into the core of the script. Not knowing how to write a plugin architecture, I have been looking for/at other PHP scripts that do this.
The prime example is “Smarty”:http://smarty.php.net but I haven’t figured out yet how to apply it to a non-compiling form, or a script that needs flexibility in the positioning of the output elements.
Other examples are the proverbial *Nuke scripts et al, but these seemed on closer inspection to be too different to help with FormProcessor - although I would like to understand how they work to do something similar in some of my projects.
Incidentally “sendcard”:http://www.sendcard.org was one of the first PHP scripts to have support for plugins - with a twist. When I wrote it I didn’t like the thought of checking a plugin array 20+ times during the script execution, so I wrote the plugin engine to insert the code directly into the main script files. It works well, but is a bit of a security risk, as the PHP files have to be group and/or world writable for it to work on most servers.
The more I look at adding plugins to FormProcessor the more I want to be able to parse the whole page into a DOM-tree and then add new nodes in places. That way I could stick Javascript in the and modify attributes for the
Otherwise it’s going to be very hard to get plugins to do much..
Well, maybe not. The situation today is fast moving from being a joke to a nuisance. Intergrating existing scripts is harder if they use different template engines; if you’re writing a library that outputs any (X)HTML you either tie it to a specific template engine, write renderers for many different systems, or forget about easy editing of the output at all and embed the (X)HTML.
Look at PEAR’s HTML_Quickform. It comes with *eight* different renderers. Now OK, they’re not all for specific template engines, but it gives an idea of the task involved.
If you do the design work, chances are you’ll work most of the time with one template syntax. Then a script is integrated into the website, and you’ve got another syntax to master, while the developer has to find a way to inject the output of the new script into the existing template (unless you want to maintain duplicate header/footer templates). The more scripts, the more the problem multiplies.
It’s also a lot of duplicate effort. “PHP Classes”:http://www.phpclasses.org/ lists “50 template engines”:http://www.phpclasses.org/browse/class/37.html at the time of writing; “PEAR”:http://pear.php.net list 5 template packages. Was there nothing else for these people to spend their time doing?
PHP needs a recommended template system. OK, maybe 2 systems (simple and advanced) with compatible syntaxes, so you can upgrade from the simple to the advanced with no problems.
Plus, if you’re a maximiser like myself, a recommended template engine saves the time wasted dithering over which system to use _(as I’ve been doing for my RSS Manager…)_
This is the first in an occasional series on writing faster executing PHP code. Eventually I’ll finish the test suite I started about this time last year to show the demos live on this website complete with source; for now it’ll all have to go in a weblog entry
First up is require_once. A nice convenience function, is it worth the speed hit involved?
h2. Testing criteria
To test the speed of the function calls the file I include is as small as it could be:
bc.
This prevents the test from being muddied by the compliation speed of the PHP code. However, you must remember that this does mean if your hosting provider doesn’t use a bytecode cache, then you most likely won’t appreciate any speed-up caused by optimising your code in this way.
h2. Results
h3. Using require_once
time index
ex time
%
Start
1072025702.37311600
-
0.00%
Before re-include
1072025702.37346400
0.000348
71.17%
Stop
1072025702.37360500
0.000141
28.83%
total
-
0.000489
100.00%
h3. Using require and a defined constant
time index
ex time
%
Start
1072025698.95371700
-
0.00%
Before re-include
1072025698.95406200
0.000345
91.03%
Stop
1072025698.95409600
0.000034
8.97%
total
-
0.000379
100.00%
As you can see, using @require@ produces over a 3x speed-up compared with @require_once@. But *what happens if we use a bigger class?*
h2. Second Experiment
I tested this by including “PEAR’s”:http://pear.php.net DB class into the script (change source code references from test.php to DB.php; and the constant ALREADY_INCLUDED to DB_OK) as this was the biggest class I could easily lay my hands on.
_Important:_ DB.php did not have to include PEAR.php as Benchmark/Timer.php had already done so - therefore less code was included than I first thought. Still, it’s already a pretty hefty chunk
h2. Results
h3. Using require_once
time index
ex time
%
Start
1072026680.34563400
-
0.00%
Before re-include
1072026680.35255600
0.006922
96.96%
Stop
1072026680.35277300
0.000217
3.04%
total
-
0.007139
100.00%
h3. require and defined constant
time index
ex time
%
Start
1072026688.33523100
-
0.00%
Before re-include
1072026688.34217500
0.006944
99.21%
Stop
1072026688.34223000
0.000055
0.79%
total
-
0.006999
100.00%
This time, approximately a 4x speed-up over using require_once for the second time. Are 150 microseconds worth saving? Maybe if your site is heavily frequented; but the effort’s probably not worth it otherwise.
h2. Rating
Speed-up: 1
Ease: 4 but makes more hassle
Is this change worth it? Certainly not if you aren’t using a cache, or if you’re using huge classes