Well... That was... Humiliating.
Well it looks like RMI is the way to go after all. I really wish Perl had something comparable, and better garbage collection -- circular data structures are very convenient. Thankfully the problem domain is fairly simple, and reimplementing what I have already wont be too hard or time consuming.
Anyway, that may or may not be a priority in the Very Near Future. I've got higher priority stuff to focus on at work.
I am however considering defining my own XML language for vocabulary translations. I.E. to help me memorize Japanese vocabulary... *grin* Am I duplicating any efforts? I hope not... I'll be posting the DTD or specification on my site, along with reference code when I get the chance...
I haven't tried messing with global-IMEs and Unicode display in Java or Perl... Any advice?
Nihongo wa utsukushii to muzukashii desu.
Anyway, I miss my sweetie... I didn't see her today. :( Apparently however she and her mom nearly got killed on the way to dinner -- moron ran a long-since red light at around 50MPH. Her mom stopped just in time. He just waved as he blew by... Some people really need to be removed from the gene pool for the sake of the rest of humanity.
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. :)
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 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!