Emacs FAIL

Okay, no. I gave it a try for a good week. And by the end of the week, I don’t have any way to change basic stuff like fonts or colours, completion is still a mystery, line numbers are buggy, and I’ve not yet seen one single function that made me say “y’know, it’s a pain, but it’s worth it”. I wound up getting not one extra page added to the RCMS project during the entire week because of emacs configuration hell. Frac that for a game of soldiers.

I’ll stick with vim 7. Completion? Got it. Reformatting code? Got it. Testing code syntax in the editor? Got it.

And now, on with the actual work. Y’know, the thing we’re meant to use the editor for in the first place?

Emacs

Hmmm. I started programming on an old ICL OPD (anyone else remember microdrives?). There was some fooling about afterwards with an IBM PS/2 system (woo-hoo, 40Mb of hard disk space!), but the first time I hit what I thought of as a real machine was on a unix account in the first week of college. And that’s when I first hit the biggest question any starting computer engineer hits (or used to hit, back then): Vi or Emacs.

Back then, I chose Vi by default, in that it was the first thing I came across and command/edit mode switching actually made sense to me. And I used vi for a good while afterwards, until I finally found, and immediately switched to, vim. I’ve used vim ever since for any task where I could use it on any platform where I could get it (in fact, not being able to use it for wordpress blogging ticks me off). Being able to run around a source code file in command mode and dd or y lines from here and p them over there, or J them together or call up boxes with an <F4> remap to give me a nice easy-to-spot function header, those are things I’ve gotten down to the reflex level at this stage. In short, I like vim. It’s small, fast, uncluttered. And don’t talk to me about tabbed editing and intellisense and debugger integration please, that’s been in vim for quite some time if you want it (and frankly, if you’re using Visual Studio anything and telling me it has a better editor, you seriously need to stop wasting your time). Not to mention the fact that everytime I’ve seen something like intellisense in actual use, it’s been used by some rather lazy programmers. Which isn’t to say that brace completion and the like can’t be used by good programmers, just that my impression so far hasn’t been a good one. Lie down with dogs, get fleas in your keyboard…

Anyway, the thing is, I’m familiar with the claims about the immense customisability and power in Emacs, but by the time I’d started to hear about it, I’d learnt vi, and once you learn an editor and there’s work to be done, it’s hard to justify the effort to relearn another one. Feels too much like faffing about. But right now, work’s in the research phase (ie.  Feck! Why won’t that work? Damn, go read the devel mailing list archives and the code…), and I have my little side project for the rifle club tootling away, and apparently XEmacs/GNU Emacs is now a run race and GNU Emacs is now a full superset of xemacs so there’s an easy install choice, and GNU Emacs 22 supports mercurial (there’s a blog post in there on its own methinks) out of the package, and PHP with a simple apt-get install, and the more tools you can use the better, right?

So I’ve installed a basic GNU Emacs setup on the work and home boxen with a PHP major mode, and over the next week or so, I’m going to try to use it for my side project. If that takes off, I’ll think about using it for the main project and where it fits into my toolbox overall. I suspect vim’s still a winner where another app has to call an editor (VCS commits from a command line and such) or where you’re running round /etc trying to fix something, but we’ll have to see.

First thing I have to figure out is what the emacs equivalent to command mode and edit mode are…

Multiple databases in Drupal

Have to say, while MDB2 has the more straightforward way of accessing multiple databases (just create more database objects using MDB2::factory()), drupal’s way of doing things is a long way from horrible.

To initialise:

$db_url['default'] = 'mysql://drupal:drupal@localhost/drupal';
$db_url['mydb'] = 'mysql://user:pwd@localhost/anotherdb';
$db_url['db3'] = 'mysql://user:pwd@localhost/yetanotherdb';

And then to use:

db_set_active('mydb');
db_query('SELECT * FROM table_in_anotherdb');
//Switch back to the default connection when finished.
db_set_active('default');

Quite straightfoward looking. Now to see if it actually works!

4’s dead baby

So PHP 4.4.8 is released, and that’s it for the whole PHP 4 line. No further normal releases are due and PHP 4 is no longer supported. Hopefully this will mean that the takeup figures for 5 get a sudden sharp upwards jolt!

It’s going to be interesting to watch as major apps like Drupal change over from having to provide legacy support for PHP4 and can start to use the better object model in 5 – the question will be, will we see an improvement in the quality of coding as the mainstream toolset improves?

Reaching the limits of PHP

First off, I rather like PHP. PHP 5 at least, I think PHP 4 was – and remains – a dog’s dinner of a thing at best. But for 90% (at least) of webpages, PHP is a pretty decent solution. Retrieval of data from databases, display of that data, no worries. Minimal learning curve, support for high-level constructs like objects and exceptions, several frameworks available – PHP’s a damn good choice in the vast majority of cases.

Thing is, right now I’m trying to put together a bit of code to act as a proof of concept, and – more fool me – I tried to use PHP to do it, figuring I’d save some time. No such luck. Turns out, trying to create data in PHP is a lot harder than trying to manipulate or display it. Right now, I’m in the middle of implementing a recognition system using a variable order markov model approach, and just generating the PPM-C prefix trees is a total pain in the fundament. Even the basic data structure I’m using – a trie – has no standard implementation in PEAR or the SPL or anywhere else I could find. So first I have to write that. Then I have to write the code to do all the other stuff. I mean, granted, hoping to find a pre-written PPM library was a bit hopeful, but prefix trees are basic data structures (and yes, I eventually found some sample code for one, but I’m still having to kick that about a fair bit to get what I need from it). But there was other stuff that I tried and ran into problems with. For example, PEAR::Math_Matrix seems to be PHP4 only, and the PEAR version doesn’t want to even parse in PHP5, let alone let me look for determinents or jacobians or eigenvalues. Which put yet another crimp in my plans earlier this week.

Anyway, for the actual production version of this project, PHP’s obviously out and never was in the running. This piece of code has to run as fast as possible – so I’m looking at C++ or C or something of that nature. But for proof of concept, I was hoping PHP was the way to go. Nope. This horse does not do well on this course. I’m thinking it’s time to start playing a bit more with Python or Perl or something for this sort of thing in the future. Which isn’t horrible – better to have more strings to your bow if at all possible. But it does rather shoot the whole fanboy attitude in the PHP-vs-Ruby-vs-Python-vs-Whatever language wars. There’s simply no place for it in a professional environment, and it’s not of any real use anywhere else either.

Still gonna do that rifle club management system project in PHP with Symfony or Prado (if they get the menu component done and released in time) though.

(And someone needs to tell Sean Coates that Microsoft is still evil )

Prado

On a seperate project from the PEAR work I’ve been doing of late, I’ve just rewritten an earlier project to use the Prado framework. I spent some time a while back looking at various frameworks, and in the end came down to a choice between Symfony and Prado. Because of the way this current project works, I thought Prado’s event-driven model was an easier fit than Symfony’s MVC model. Mind you, for other projects (including the one I was using PEAR for), I think Symfony would be ideal (and I didn’t use it earlier only because of time pressure).

Happily, the front-end of the project I was refactoring into Prado had no work done on it at all (the previous version was effectively a proof-of-concept with all the work in the back end). Still though, if I had to do it over, I’d probably quote an extra week and rewrite the whole thing from scratch using ActiveRecord instead of the custom database interaction I had in this version.

Some of the stuff in Prado isn’t quite as optimal as I’d hoped, mind. For example, nesting templates in Prado doesn’t work fully in that if you have Template C nested in Template B nested in Template A, then a variable in Template A is not visible at all to Template C, and the code attached to Template C can’t change it. So you have to have a TContentPlaceholder in Template A and a TContent linked to that in Template B, containing a TContentPlaceholder which a TContent in Template C links to and that TContent in Template C contains the actual content. It’s suboptimal and messy, because you’re effectively doing inheritance on a pseudo-object by hand, and typos can waste lots of your time, not to mention the headache of keeping it all straight as you code.

And there’s no tree control. And there’s no built-in menu control (though that is up for the next version to be fair, but still, it’s a right pain in the touche to code a fake menu using and CSS, and it’s such a basic kind of control that I thought it bore mentioning in a complaint!).

However, little bits like this are, in the end game, just niggles. Compared to trying to do what Prado does for you out of the gate, you’re light years ahead of the curve when using the framework. Yes, I know, that’s a well-established fact for frameworks and noone’s learning anything new from it, but I thought I’d just point out that it holds for Prado and that Prado’s approach of an event-based model as opposed to an MVC model means that it’s a more comfortable fit for something with a lot of user interaction like the last project I was on.

I mean, for an example, you can build your pages in Prado with no backing PHP code whatsoever, show it to the client for a scratch-n-sniff test, and if it gets their okay, you go code it up; if not, you edit what is pretty close to HTML code and try again. Very fast turn-around that way.

I’m looking forward to v3.1.2 and the new tree/menu control, and once that comes out, I’ve got that little RCMS project I’ve been meaning to write for a few years now that should make for a nice little testbed…

PEAR::Structures_Datagrid

Okay, so to all those who wrote this lovely little library, thank you!
Refactoring old code to use this wound up saving me quite a few days of programming time and let me export Excel files instead of the usual cheat (although if it gives a more portable format, is it really a cheat?) of exporting CSV files.

PEAR

Doing some work refactoring old hand-written code using PEAR libraries at the moment. Just have to say, structures_datagrid and HTML_Table_Matrix are very, very useful tools sometimes…

Unicode math symbols as operators in PHP6?

Noted over on Sara Golemon’s blog today. Can we expect this sort of thing to be in future PHP code?

var_dump(¼, ½ ¾);
// float(0.25)
// float(0.5)
// float(0.75)

var_dump(1 ≤ 2, 2 ≯ 3, 5 ≠ 6);
// bool(true)
// bool(true)
// bool(true)

var_dump(3 × 4, 15 ÷ 5);
// int(12)
// int(3)

var_dump(1 « 3);
// int(8)

/* Your font may be too small,
 * but that's a skull and crossbones */
☠('aka die/exit');

Well, no, not really – she implemented it just for fun, but it’s an interesting idea, and face it – who doesn’t want to be able to use all the keys on the Space Cadet Keyboard?

Xdebug 2.0 released

Hmmm. First PHP application programmers start GoPHP5.org, then the php core team announces the EOL for PHP4, then namespaces get added into PHP6, and now Xdebug 2.0 is finally released. It’s not quite the precambrian, but it’s definitely been a busy few days!

Xdebug, for those of you who prefer to debug PHP code using echo and var_dump(), is a bloody lovely zend extension for php that lets you get proper debugging information for when stuff goes pear-shaped (excuse the pun). From the official announcement:

It is finally here, Xdebug 2.0.0 has arrived! After about four years of work I finally found it ready to release. Have fun! After almost four years of work, Xdebug 2 is finally ready. With improved functionality and many new features it is ready to totally change the way you develop in PHP. Some of the new features and updates include improved stack traces, execution traces to files, code coverage analysis and much improved remote debugging support. Xdebug’s documentation has also been rewritten for more clarity.

I’m leaving it for Monday to install at work, but I’m going to check the installation goes okay at home over the weekend. Finally getting function traces without having to call PEAR::Log every five microseconds? Yes please! And nicely timed just before a bout of dev work in the office too

.