January 03, 2004

Today is a very good day

Because today I finished up the first draft version of the database access RTL for the big work project. Yeah, it's really fragile, and likely to fall over in odd ways when stressed, and the DB schema itself still needs a touch of work (missing UNIQUEs on the primary index) but... it works. I can insert, delete, and read records, as well as going forward and backwards through the DB table in primary key order. I still need to work on partial key matching, and walking forward through a partial key match set, but that's next, and I can probably put it off for a little bit. But hey, it works, and it's kinda cool to watch what's going on in a separate terminal window from the Postgres psql client.

Between this and the curses-based screen RTL code, the runtime for the DecisionPlus translation project is done enough to use, which means now all I have to do is whack the compiler some to use the RTL as it really looks, rather than how I thought it would work when I was doing the last pass. I fully expect quite a few "What the hell was I thinking?" moments. Who knows, if this goes well, maybe I'll nudge the good folks around the office to let me release the required SQL and bytecode for a working Parrot demo, though I'm not sure any demo that starts with "Use this SQL to create a new table in your Postgres 7.4 or higher Postgres database" will be all that popular.

I should note, for those following along at home, that this is all in Parrot. With a stock (well, latest CVS checkout if you're non a non-x86 platform, or on an x86 platform without the JIT1) interpreter no less. While the resulting bytecode file's a bit big (with the ncurses and postgres wrapper libraries, and the language-specific screen and db RTL a test program's 84K of bytecode, but that's off of 91K of source, so I suppose it's not too bad) it works, and the time to fire up parrot, load in the bytecode, connect to the database (running locally), insert 32 records, delete 1, and fetch 4 is 1.9 seconds. And that includes a 1 second sleep as part of the DB connection code. (Postgres has this weird asynchronous connection scheme where you have to make the connect request then poll to see if it's done. Don't ask, it's just one of those things apparently) 0.14 seconds of combined system/user time total, which is definitely Not Bad.

It's all coming along surprisingly well. It's not even impossible that I might make the Jan 9th demo deadline for this. (I'll definitely have the demo version ready to run for NordU, and if I miss the 9th I still ought to have it for the Boston.pm meeting on the 13th) That'd be nice, as there's lunch for the department on the line, and I'd not like to get between everyone and that... :)

1 We had to add in a number of NCI function signatures for Postgres 7.4, which I'm using because it has placeholders, and placeholders make life very much easier. Parrot's JIT can build the function calls dynamically on x86 platforms, but at the moment we can't do that elsewhere, so we have to have a wad of precompiled function signatures built into Parrot as a stopgap, so you need the latest version to make it all work. Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere.

Posted by Dan at January 3, 2004 05:11 PM | TrackBack (1)

Congrats on the DecisionPlus work.

Just thought I'd state here for the record that I am planning to rework the DBI/DBD architecture for Parrot. I'm currently working on moving DBI to sourceforge and then I'll be creating a new branch for a v2 release. The changes in v2 will be mostly in the DBI-to-DBD API, including defining and documenting the interface more clearly with a view to it acting as the model for Parrot DBD's.

It's early days yet but anyone wanting to help out now should start working on an NCI interface for their favourite database.

Posted by: Tim Bunce at January 10, 2004 06:28 AM

Back in August 2000, I asked Bruno if he'd be willing to loosen the licensing terms of libffi for use with Parrot. He said he'd go as far as LGPL, but not Artistic.


Posted by: Garrett Goebel at January 12, 2004 09:58 AM

I definitely don't look forward to the prospect of unifying the DBD/DBI stuff, as there's Perl, Ruby, and Python versions to deal with. Possibly PHP as well, but that one I'm not sure of. We're going to end up having to support module name, version, author, and base language in module loading determinations, I think, just to sort that (and some other basic ones -- CGI, GD, Tk...) out.

Posted by: Dan at January 12, 2004 10:52 AM

As for the libffi stuff... what we probably ought to do is make the nci build code clever enough to use our JIT if we have it, the system libnci if we don't, and fall back on the massive evil hack we have now if that doesn't work out.

One more for the TODO list...

Posted by: Dan at January 12, 2004 10:54 AM

my bad. I confused libffi with bruno's ffcall.

The libffi was originally produced by Cygnus, but is now actively maintained
as part of GCC.


ffcall was produced by Bruno Haibel as part of his CLISP package. It used to be considered more mature/stable, but since libffi was included in GCC the general impression true or not, is that it is more actively maintained.

Posted by: Garrett Goebel at January 12, 2004 01:58 PM

Unifying the DBD/DBI stuff for multiple languages is one of my goals. Parrot is supposed to make that simple at the VM level - I just need to deal with any differences between the DBD's. I'm focusing at the moment on the DBD API as I figure each language will have it's own DBI layered over a common set of DBD's working to a common DBD API spec.

Parrot will have to deal with module name, version, author, and base language in module loading determinations, but that's not a significant issue in the short term. It's all alpha anyway and names are easy to change.

Posted by: Tim Bunce at January 12, 2004 02:18 PM