21st Century Digital Boy

I needed to rebuild PHP to add SOAP support. (Side note: when will it be reasonable to add functionality w/o rebuilding the core binary, like, oh, every other language in the world?)

Obviously I want to preserve build options, and just tack on a new one. So:


# php -i | grep “Configure Command” | sed -e ’s/Configure Command => //’ -e “s/’//g”


Just just a flick of the mouse, add my new option, and endlessly whine that PHP makes me rebuild the binary eleventy million times a month.

Update. So I figured this one out. Turns out it was working in 4 and not 5. Remember, kids:

$roscoe = new HoundDog();
$otherdog = $roscoe;

works in PHP4 but for PHP5, one must

$otherdog = clone $roscoe;


So what was happening was, someone was changing rdelim and ldelim somewhere, and under 5 it was failing because the copied object was inheriting the munged r/ldelim; so all parsing failed.

***
Google has failed me.

I have a large, non-trivial application that makes extensive use of Smarty. Now, I know I’m not supposed to be using Smarty any more, but that’s not an option, here. (If it makes you feel any better, it’s on the TODO list.)

What’s happening is, calling a page returns the unparsed output.

This is ordinarily uninteresting, except that if I manually run around including all the parts of the application I get parsed (correct) output. (Mostly, I don’t know that I had the entire shebang working, but I can get output).n

More interesting, the application in question ships with its own Smarty (it’s not using anything on the system) and works great on Linux. Using the same versions (as close as possible anyway) on Mac OS X results in the fucked-up output.

We kinda need to be able to run said app on Mac OS X. Since it’s our dev platform and all. Our deployment platform is Linux. FWIW it fails in both PHP4 and PHP5.

If you’re curious, it fails here:

$search = “~{$ldq}\*(.*?)\*{$rdq}|{$ldq}\s*literal\s*{$rdq}(.*?){$ldq}\s*/literal\s*{$rdq}|{$ldq}\s*php\s*{$rdq}(.*?){$ldq}\s*/php\s*{$rdq}~s”;
preg_match_all($search, $source_content, $match, PREG_SET_ORDER);

(this is around line 257 of Smarty_Compiler.class.php)
$source_content never matches anything, ever, and so it becomes one giant pass-through; _compile_tag() is never called, because the above match fails (and the one right below it that finds the tags to compile). but paste that code and the source, and it finds it perfectly.

I can compile the templates anywhere but within my application (ie, I can write my own smarty thingee and get something compiled).

My google-fu has failed me, because everything always comes back as some tard can’t get his templates to compile because he can’t write to his stupid compile dir or even include the class. I wish it was that simple.


[gregg@Tardis: ~/tmp]$ php -a
Interactive shell

php > require_once ‘Zend/Config.php’;
Segmentation fault
[gregg@Tardis: ~/tmp]$


Ooops?

So I have been porting a little web app I wrote in plain ol’ procedural PHP to Zend Framework. Slow going, but I’m still getting the hang of ZF and translating this crap PHP to good PHP (ie, I’ve spent as much time asking “How does ZF handle foo” as saying “Why the fuck did I do it like this in the first place”).

I don’t want to have to maintain a separate “library” of view helpers that my team (the Little Brains) will then fuck up all over the place. (Sorry, but the technology has to be smart, as they are … not.)

OK yeah, the working answer seems to be $this->view->addHelperPath(’blah’, ‘PREFIX_’); in the controller method, and not mucking about with a new Zend_View thingee (ie, $view = new Zend_View() and so on). I assume somewhere I missed a method call doing it the hard way? I dunno.

I guess the other answer here is extend a base class, like Zend did with their form helpers .. you still have eleventy billion helpers but at least you can centralize all the common shit.

So I’m writing this “admin app” for another, customer-facing app, and I’m bored and angry because I have to run around trapping and responding too errors that occur in the front-end, so whomever is “on duty” can know the why-what-where-who-the-fuck of any issues.

And suddenly I’m aware of my time test-driving the Zend Platform, and its little real-time error trapping stuff, and how I could drastically simplify this by merely saying, “if error A occurs, do this; else look up the error event in the Zend back-end”.

So that wasn’t working for me. I kept getting bullshit errors a la, “checking whether build with IMAP works… no”.

Turns out the answer was, ‘ranlib - libc-client.a’ then configure on php. This is also why I fuckin’ hate PHP.

The PHP world is talking about namespaces again. Here’s what I don’t get: why do we need a require, if we already “spell” the file’s physical path? After all, we already know where the files live, right?In short, why can’t ‘$fred = new Foo::Bar;’ automagically include $INCLUDE_PATH/Foo/Bar.php?Works in Perl, Python, Ruby….