This post originated from an RSS feed registered with PHP Buzz
by Alan Knowles.
Original Post: 2d Latest in Vapourware, PintCompiler & dbdo 15
Feed Title: Smoking toooo much PHP
Feed URL: http://www.akbkhome.com/blog.php/RSS.xml
Feed Description: More than just a blog :)
10e7
Most days I work on paid projects (or try to), while they sometimes offer an intellectual challenge (like hacking up xul trees in javascript [it's amazing how javascript is actually usable on Mozilla, rather than the absolute nightmare it is on IE]), or some pleasant company (doing maintenance at a yacht club). It tends to be more the exception than the rule. Most of the day is spent going through lists of changes that have been discussed and modifying databases, interfaces, and ocassionally fixing up someone else's code.
So to prevent insanity creeping in, I try and find something interesting to attack in the evening. In the last few weeks I've had 2 projects ticking away, both of them have big question marks about whether they get finished (like phpmole,DB_DataObjects), or get abandoned in the wastland of muse's (like PHP#, BinaryPHP). Anyway only time will tell.
PintCompiler
Sterling, Thies and a few others, have been busy investigating PHP for Parrot, I had a chance to browse the code a couple of weeks ago. Last time I saw it was at the PHP conference last November, which was a bit chaotic, so although I did start trying to hack up a compiler in PHP to do the same thing, the phpSharp code base I was using wasnt quite ready..
Fast forward 9 months later, having hacked in a Abstract Syntax tree into BinaryPHP, I now had a Tree that parsed PHP code, which could theoretically be refactored quickly to write a generator for any type of bytecode. It took exactly 3 evenings to modify the BinaryPHP tree builder/generator to get the first hello world's working, along with some basic maths etc.
Pint originally had about 6 test PHP files, the most complex a mandelprot calculation however proved to be difficult to implement. Mainly based on a poor assumption I made in designing the code generator. I had assumed it would be a good idea to keep the number of temporary vars down to a minimum, and reuse them where possible. This was a BIG! mistake. Due to the way variables are objects, and need cloning explicity, if you try and reuse a variable and forget to clone, you tend to end up changing the first variable value by accident. Luckly to get it working properly is probably just a matter of reducing the redundant extra clone'ing opcodes, and removing the temporary variable stack code.. http://devel.akbkhome.com/svn/index.php/PintCompiler/
DBDO - DB_DataObjects as a PHP extension.
http://devel.akbkhome.com/svn/index.php/dbdo/ I had been toying with this idea for a while, DataObjects, while being a godsend for development, has a ended up with little issues that are totally unfixable, while it remains in PHP. some of the biggest being, how to reduce the print_r() size, and how to determine which variables have changed, when building the update/insert requests.
So after spending a week or so looking at potential backends (libgda, libdbi and pdo), My major preference out of all these was libgda, for a number of reasons. Interesting Design, alot of Backends, Great Documentation and it uses the glib/gobject stuff that I've used a couple of times over the years. Although the mailing list is quiet, compared to most of the php ones, the developer's list seemed to be getting things done. It was a close call, there where alot of other deciding factors, libgda's type library was pretty convincing, and introspection features made it pretty compelling.
While no where near completed (and leaking memory like a seive) After 3 late nights, I have alot of what I thought would be the more complex stuff working: - >>>> read the extended entry to find out more (as this intro is long enough).. >>>
20
Previous Topic
