Older blog entries for jfrisby (starting at number 2)

Hmmm... Is the Perl interface to PVM *really* that out of date? The most current one according to the PVM web site and CPAN is from '96. Bleh!

Well, I'm not even sure PVM is the right tool for this job. Essentially I have a tree structure, where each node is a work unit and is dependent upon the results of rendering its children.

Rendering a node involves:
1) Gathering inherited information from the child nodes.
2) Gathering node-local information from the database.
3) Winnowing down the data to the relevent subset.
4) Producing output files (2 per node).
5) Returning the subset data to the parent node.

I've had PVM and MPI suggested to me as starting points, although it seems that moving to Java and RMI might be better for the situation...

Gerry says PVM is probably inappropriate since my code has side- effects (step #4), but Wayne (who suggested PVM/MPI initially) says that RMI may be inappropriate because of the volume of data being passed around -- individually the data set returned to a parent is small, but there can be lots of children.

I still need to look the PVM vs. MPI comparison on the PVM site -- being on Windows, viewing PostScript files is kind of a chore.

Any input or advice?

On a (*grin*) personal note: My girlfriend is awesome. It's really cool to have someone who will give you an 8:00AM wake-up call, even if that means calling epeatedly for 10 minutes straight until you wake up. :)

Wow... Advogato is cool. :)

Raph pointed me to the TIGER/Line database, and Benjy dropped me an e-mail pointing me to Bruce Perens' site, where a Free copy can be found. Cool.

I'm on a deadline so I can't review the data just yet, but I imagine it has everything I'm looking for. I can't wait to OS this job database...

I should be up-front in pointing out that the system is back-end only... All the extant front-end code sucks and uses unusual tools (the best front-end code -- from the now defunct BrainPower -- uses ePerl... MrJoy.com uses HTML::Mason but the front-end is extremely crude and tightly integrated with the rest of MrJoy.com). Basically it's a high-level Perl API and database schema for posting/modifying jobs, etc. It's carved out of a larger system so some things will seem a little incomplete...

I may include my e-mail processor that lets you handle e- mailed job submissions -- using a special format -- but it's kind of clunky. I'd much rather rewrite it to use an XML language to define the jobs first.

The e-mail handler was made to work with QMail, but I've made a POP3 wrapper which can be run as a cron job... Currently the API only supports MySQL, but I'd like to port it to Postgres as well, and add support for BDB transactions in MySQL 3.23...

The job engine really hits MySQL in it's weak spots. Performance can really grind because of uber-complex queries. Feh. MySQL really needs sub-selects.

BTW, anyone looking for actual open source stuff I've written can check out MrJoy (click on "Software") or check out MasonHQ under the contributions section. It's all really trivial stuff, but it works. :)

Given the response to my last question, I'll pose another one: What ever happened to the plans to have proper garbage collection in Perl? I drove myself batty recently trying to eliminate an unintentionally circular data structure... *grumble*

On a personal note, my sweetie is great. :) She can be a tad emotional at times, but I have some of the same issues she does so I understand how she feels when her mood takes a nosedive...

I need to buy her some flowers. I haven't done that yet. I should also take her for dinner at AP Stumps or some such... The nicest place I've taken her so far is Macaroni Grill.

So where does one go to find Free data? I have a really cool piece of code I'd like to release, but for part of its search capabilities it needs a database of Zip/Area/MSA Codes.

The USPS apparently charges an annual subscription fee to get the raw data and numerous other companies integrate it (zip and area code data are normally entirely seperate for example) and then resell it.

My only options are to remove most of the location-search functionality from my code (you can search for data that is "near" where you specify, you can enter zip codes, area codes, etc...) leaving just the raw location search, or mandate that users buy this database. Unfortunately the location search is pretty key...

What then should I do?

On a personal note, I'm happy. I like my girlfriend. :) Jen is the reason I get up in the morning now...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!