Archive for January, 2006

things and … and stuff and … ‘n stuff

Sunday, January 29th, 2006

The thing is: one thing transformed/mutated/projected through something else, onto/into a third something else. Right. Gotta remember that.

Also, I’ve determined that next Halloween, I’m going to be Chairman Kaga from the original Iron Chef. (Did you know that he was Jean Valjean in one of the Japanese productions of Les Misérables? Wow.)

but seriously

Tuesday, January 24th, 2006



this whole time thing is really starting to freak me out.

It really, really just keeps going. Like … all the time.

randomosity

Monday, January 23rd, 2006

Turns out getting CamelBones to do what I need isn’t as straightforward as one might hope, either. Meh. I suppose there is a downside to free internet yayness.

I’ve signed up for feedlounge and think it’s über-spiff so far. The UI is really a work. Clean, simple, easy. Bravo, Alex. (And Scott, but I don’t know him. =) )

I’m extracting a static dump of Wikipedia as an avenue to test some things for my project. The extraction program is 7za, and it’s been using 80-90% of one of the two 2-GHz G5s for about 24 hours now. Wikipedia is big. The article names pass by as they’re extracted. Some of the impossibly obscure topics are pretty funny.

Preferablly I’d hit the Wikipedia database to get the information I need. It is not publically accessible. Second option is to screen-scrape the live site, but they obviously don’t like people doing this (even though I’m doing it for non-evil purposes and throttle the request frequency) and I guess they have defenses in place to prevent it: my requests for pages come back empty. Setting the user-agent string to imitate a real browser seemed to work at one point but now it’s not. I dunno, I suppose there’s something else going on?

i don’t even know perl

Sunday, January 22nd, 2006

Since I’ve been building software on my own for the last few months, I’ve been able to choose my technologies. (As opposed to building for someone else; in which case you’re probably told what you can use.)

I’ve been extremely impressed with the amount of information and code freely available out there. By using Other Peoples’ Code or at least Other Peoples’ Knowledge, I’ve been able to dissolve many man-months of development time. Yay internets!

So I will try to give back as I solve problems, going forward, just by posting what I learn.

I suppose in the near term I’ll post here, but I have a site and domain name for whatever fruits come from my little computer-geek renaissance here. I’ll switch to that eventually.


Right now, I want to embed a perl interpreter in my Cocoa app and run some perl code. There are apparently two already-working ways to do this. There’s Camelbones and there’s Apple’s PerlObjCBridge.

I’ve downloaded the former and may go that route, but would rather use Apple’s doo-dad ’cause it’s built-in and relatively light-weight. Camelbones will let you write OSX GUI apps in perl; I just want to run faceless perl code from a Cocoa app and get its output.

So my problem is that every reference to PerlObjCBridge I’ve found through google only talks about how to access the ObjC runtime from perl, and provides no example of how to go the other way: make a perl object in ObjC and tell it “go”. Every reference. I admit, it’s super-cool that your little perl program can be a first-class OSX citizen, but just tell me which header to include to do the other and I’ll be on my way.

I’ll post when I figure it out.

[update] - Okay, it looks like the way to bridge to perl from Cocoa with PerlObjCBridge is to launch an NSTask to run OS X’s built-in perl interpreter in a sort of client/server relationship. An adequate solution, but not quite what I’m looking for. Found this by downloading the MathServerDO example from this article.