Is the ability to display a couple of extra non-standard headers in addition to the usual From, Subject and Date stuff.
I know I can turn on all the headers, but that's just a bit too much noise.
Maybe someone out there can write an extension for that?
[PS: I know this isn't strictly PHP based, but since I spend a lot of time managing the php.net mail server, I guess it could be construed as PHP].
Yesterday I added the product of my weekend-of-hackery to PECL: the event extension.
PECL::event implements an event based scheduling engine that will execute a callback when a particular event is triggered. The various different triggers allowed are:
As you might have already guessed, PECL::event is probably most useful for longer-lived scripts that need to perform more than network "operation" without either taking too long (why do one after the other if you can do both at the same time?) or without one blocking the other and making it time out.
I've previously given a talk (or was it a magazine article?) on multiplexing with streams in PHP; this extension takes things a step further by taking the complex scheduling logic out of your script. As a bonus, it can also take advantage of the more scalable IO scheduling interfaces (epoll(4), kqueue, /dev/poll, poll(2) and select(2)) available on various different operating systems. Scalable is one of those phrases that can easily be misinterpreted, so in this context more scalable means lower overhead per file descriptor , which should translate to faster execution time in your script.
In practice, you probably won't notice much difference between the different engines in PECL::event, but you should notice the difference between a userspace implementation using stream_select() and PECL::event.
How do I use it?
<?php # our callback function readable($stream, $mask, $arg) { if ($mask & EV_READ) { echo "$arg is readable:\\n"; echo fread($stream, 8192); fwrite($stream, "QUIT\\r\\n"); fclose($stream); } } # detect and activate the best available scheduling engine event_init(); # create a new event $e = event_new( # associate it with an async connection to a gmail MX stream_socket_client("tcp://gsmtp171.google.com:25", $errno, $errstr, 0, STREAM_CLIENT_CONNECT|STREAM_CLIENT_ASYNC_CONNECT), # ask the engine to tell us when it is ready to read EV_READ, # tell it to call the 'readable' function when triggered 'readable', # and pass in the following string as an argument 'gmail mx'); # put the event into the scheduling engine event_schedule($e); # similarly, create another event, this time connecting # to the PHP MX $e = event_new( stream_socket_client("tcp://osu1.php.net:25", $errno, $errstr, 0, STREAM_CLIENT_CONNECT|STREAM_CLIENT_ASYNC_CONNECT), EV_READ, 'readable', 'php mx'); event_schedule($e); # now service all registered events event_dispatch(); # we get here when both events have been run ?>
If you run this script, you should see it output something like this:
gmail mx is readable: 220 mx.gmail.com ESMTP 71si267099rna php mx is readable: 220-PHP is a widely-used general-purpose scripting language 220-that is especially suited for Web development and can be 220-embedded into HTML. If you are new to PHP and want to get 220-some idea of how it works, try the introductory tutorial. 220-After that, check out the online manual, and the example 220-archive sites and some of the other resources available in 220-the links section. 220- 220-Do not send UBE to this server. 220- 220 osu1.php.net ESMTP Ecelerity HEAD (r3928) Mon, 13 Dec 2004 17:59:20 -0800
You'll see the osu1 banner a couple of seconds after running the script, because that server deliberately pauses.
What's the point?
The script above connects to two SMTP servers, reads their banners and then gracefully closes the connection. So what? Big deal. I can write a much shorter script that does the same thing using just a couple of lines for each host:
<?php $fp = fsockopen('gsmtp171.google.com', 25); echo fgets($fp); fwrite($fp, "QUIT\\r\\n"); fclose($fp); $fp = fsockopen('osu1.php.net', 25); echo fgets($fp); fwrite($fp, "QUIT\\r\\n"); fclose($fp); ?>
That may be the case, but with the PECL::event approach, you're not blocking on each connection (remember, osu1 makes you wait a couple of seconds) and you're not blocking on each read. In fact, you could happily add 10s or perhaps even 100s of machines to monitor and have them all happen concurrently. Neat stuff, huh?
That's all I'm going to write for now, but before I go I'll leave you with a couple of interesting snippets if you're interested in playing with the extension.
So, we're here in Columbia, MD, USA. It's been a hell of a long week; clearing out the house was the hardest part of the whole move, but worth it in the long run.
In the end, we gave away some really nice stuff that nobody wanted (or could afford) to buy; a nearly new office quality desk, Iiyama Vision Master 510 Pro monitor, a box-o-bits including things like a Roland Sound Canvas midi module, WinTV USB etc. Heart-breaking, but it was good to reduce the amount of stuff that we own. Some of the stuff was kinda crappy or useless; for example, I had boxes of things like IO boards for 386/486 machines, ISA and PCI gfx boards, 4 brand new PSUs for the PII generation machines (they came with cases, but were not powerful enough for the PIII processors I was using at the time).
After a gruelling unknown number of hours >= 24, we had loaded up our 6 large suitcases, 2 dogs, 2 dog carriers, Juliette, Xander and myself onto a mini school bus that we had hired to drive us down to the Sheraton Skyline, the only hotel we found in the area that would accept us with our dogs, and had a goodbye meal with some of my family.
The next day we checked in at LHR terminal 4; checking in with the dogs took over an hour; they handled things pretty well, but were pleased to hop into the pet cargo containers to have somewhere to rest.
The flight itself was delayed for 45 minutes while they replaced a radio, but magically arrived at BWI 20 minutes early. Xander was really well behaved on the flight, and was quite content with playing with the buckle on his car seat for most of the journey, sleeping for most of the rest.
We got to watch Dodgeball while Xander was napping, and thoroughly enjoyed it; not as good as Zoolander (probably my favourite movie), but vastly superior to Starsky and Hutch (which could have been much better).
When we touched down, we were collected from the airport by a friend/client (who lives within a reasonable distance of the airport) and his "Savannah GMC Van of Terror"; a 12 seater van with blacked out windows that gives airport security the heebie-jeebies.
So, here I am now, on Halloween, "borrowing" a neighbors wifi (I'm getting my own sorted out this week) blogging from our somewhat empty apartment. Mom-in-law had previously visited to drop off our car, filled with some kitchen utensils and bedding, and George and Theo have also donated a few items to make the place feel less empty; all these things help, but we're still pretty bare in here.
We're going to have to go shopping for more stuff; there's no rush for most of it, just for the stuff that annoys us the most first. Top of Juliettes list is an electric kettle, which seems to be something of a rarity here. Top of my list... hmmm, something to sit on would be nice.
A little while back I mentioned that I was Moving to America. It's taken from then until a few days ago to get the magic visa sticker attached to my passport, and now we are finally good to go.
The people shipping our stuff have been here since 9:30am and are just finishing up (it's getting close to 3pm now). I've moved a number of times in the past but this is the first time I've had someone else do the packing for me--I can't stress how much easier it is this way. If I hadn't been up all night sorting stuff into ship and skip piles, I would be feeling pretty good right about now.
Why was I up all night the night before? The answer is that it is impossible to get anything done during the day with Xander running around and, let's face it, no one really wants to pull an all-nighter when it's not essential.
We'll be spending the next couple of days getting rid of the stuff we didn't decide to take with us, and making the house look nice (we still need to sell it!).
We fly on the 29th.
I was asked to review this book recently (with an eye on how it equates to PHP), and having just gone through it, I'm quite impressed. It is well written, well structured (taking you from no knowledge and going from there) and teaches you good design principles, without beating you over the head with them.
Having completed my review, it is apparent that PHP 5 has most of the good parts from java, without bogging you down in syntax. I view this as a good thing, making it easier for programmers to drift between the two languages more easily.
If I was asked to recommend a book on java programming, I wouldn't hesitate to recommend this one. I would even consider recommending it to someone new to programming, because most of what it teaches applies equally well to other languages; it serves as a very useful primer, going into the right amount of detail, to make future employees useful regardless of the language that you're going to use.
I've been using this for a while and been annoyed by two things it does:
The latter doesn't seem fixable, but I can live with it. The Alt-F4 thing can be solved with a bit of registry hacking. First, turn off nView, so that it saves its state into the registry. Then open up regedit and create the key shown in the picture below (the full registry path can be seen in the status bar). Once you've added it, turn on nView again.
I did try VirtuaWin for a while, but it has particularly crappy interaction with the cygwin X server: switching desktops causes most of your xterm windows go into attention grabbing flashing mode. Very annoying.
Marco aims to publish a number of case studies on the adoption of PHP in small, medium, and large businesses (or enterprise, if you will) with the intention of creating a kind of marketing "war chest". The idea is to form a kind of business PHP hub that will help other businesses to make a more informed decision when it comes to adopting PHP.
Marco is looking for people to write case studies in marketing-speak to use there; for more information, read Marco's blog entry.
Xander had his first half-day at play school today. He was a little unsettled about not having either Juliette or myself near-by, but enjoyed being in the company of other kids his own age.
He produced his first artistic piece, without the aid of crayons, pictured to the left. The piece features the colour red and his favourite shape--the circle.
I've spent some hacking time this weekend improving the COM/.Net extension for PHP. I am both happy and annoyed with the results. In order to convey why I'm annoyed, you'll need a bit of background.
COM is all about interfaces. PHP uses the OLE Automation interfaces that allow run time binding of classes and methods; the key here is IDispatch. There are also a set of interfaces known as Connection Points that effectively allow an object to call you back, via another object that you supply, to be able to handle events. The guts of Connection Points are hidden away from you in VB via the WithEvents keyword. PHP also supports Connection Points and also hides the details from your script via the com_event_sink() function.
Now, .Net is similar, but not. It has a number of COM-ish concepts and even ships with the "interop" layer that will automagically map COM into .Net and vice versa. PHP uses the interop layer to bind to .Net at runtime; this is cool because it means that PHP doesn't then require the .Net runtime to be installed on the target machine.
As part of my quest for a better offline blogging tool, I thought about using .Net from PHP to get at the System.Windows.Forms classes. It quickly became apparent that there are some shortcomings with the .Net interop stuff. The theory is that .Net will map its classes to IDispatch'able interfaces via CCW's (COM Compatible Wrappers). In practice it does that, but doesn't explicitly implement the interfaces; instead, IDispatch is present implicitly in the System.Object interface. The effect of this is that the PHP stuff breaks when it sees these objects coming back out from COM, because it can't see IDispatch: .Net is being naughty.
The fix for this is simply to import the interface definition for System.Object and explicitly check for that interface in each of the places where we are looking for IDispatch. This is fine, except that it isn't simple. System.Object is defined in the mscorlib assembly. There is no mscorlib.h header file, and there is no mscorlib.idl to generate a C header file either. In order to get at this stuff I had to load up the binary type library file and export it as IDL. I then needed to hand-edit the 20k lines of IDL so that it could be compiled by MIDL (the order of many declarations was wrong). This process resulted in a 3MB mscorlib.h file (115k lines).
Armed with the header, I added support for System.Object and was able to instantiate the System.Windows.Form::Form class from PHP, set its caption and size and see it on-screen. Yay!
The next step was events, because a form that doesn't react to user input is not very useful.
Events in .Net are based on delegates. Delegates is a posh way of saying "callbacks"; your delegate is essentially a structure containing a pointer to a function or method and a pointer to the object to which the method belongs. Hooking up the event is simply a matter of telling the source object (say, a button on a form) where your delegate structure lives.
At the lower level, the procedure for hooking up a 'Click' event for a button is something like this:
With the help of our 3MB header file, we can execute this code. We need to implement the Delegate interface on our own stub, because there is no standard Delegate class that we can set up with a generic C callback function.
And this is where things fall down: .Net doesn't accept our Delegate instance because it is not managed code.
The way to get this stuff to work is to build the PHP com extension as managed code, and re-implement chunks to use the Microsoft specific extensions to C++. This poses 3 problems:
Big ouch.
A really nice clean solution would appear to be to separate the .Net stuff out in its own extension; that would solve a couple of problems, but introduce others: there are a few places that need to handle .net specific cases, and those introduce linkage dependencies on the .Net extension.
This is fixable, but we're now into the realms of work-exceeds-fun-returns, so I'm probably just going to leave things as they are. Sorry folks.
If you want events in the mean time, all the .Net docs suggest that you should instead make your own wrappers for the objects, using a .Net compatible language, and implement them as Connection Point style interfaces. The interop layer can then perform behind the scenes voodoo for the CCW's, and you should then be able to use com_event_sink() to hook up your events.
My laptop has a dual boot xp/linux install.
For a little while now, I've been running linux 98% of the time, but I've started to miss my music. In the last couple of days I've tried a number of Ogg/MP3 players on linux and have been a bit annoyed by the memory and cpu usage. I suspect a combination of bad audio and firewire drivers as being responsible for most of CPU usage. Anyway, it was making the system unusable, and I need my music.
So, I've switched back to the XP side of things for now, using vmware to get at the linux install (using a native persistent disk to provide access to the real linux partition). One of the things that annoyed me about vmware was that NAT networking sucked; it would cause my wifi to drop out and not come back, sometimes, if I rebooted the virtual machine. I also didn't like the fact that I had to run dhcpd and nat daemons. In a flash of inspiration today, I made the following adjustments to my config:
The net effect (pun not intended ;-) is to have windows perform the nat and dhcpd for vmnet8 natively. By disconnecting the VMWare Bridge Protocol, vmware leaves your NICs well alone. I've noticed better stability and less latency using this approach today.
On the linux side, I run RHEL; for vmware I boot into run level 3 instead of the usual 5. I've turned off most services in run level 3: acpid, bluetooth, autofs, sshd and all that stuff, leaving just syslog, gpm, vmware-guestd and a couple of mingetty and tweaked rc.local to stop hotplug and unload additional modules, all to reduce the memory footprint of the vm.
Back on windows, I run the Cygwin X server and use that to serve xterms up from the virtual machine (don't forget to use xhost under cygwin to allow the vm access to the X server).