A new comment on my Jan. 22 post about embedding a Perl interpreter into a Cocoa app has made me do what I meant to do today anyway: reopen that project and get to work on it again. (It’s my thesis project … if that explains the long break … )
It’s been a while, so I may have to refresh my memory, but here’s what happened.
I wound up using CamelBones. There were a couple of glitches, but that was using the beta 5 version. Version 1.0 is now out and according to the author (who I emailed) at least one of the glitches was a real bug and has been fixed in 1.0.
But yeah, with the CamelBones framework linked in, I inited an instance of the interpreter with something like this:
CBPerl* sp = nil;
NSString* appBundlePath = [ [ NSBundle mainBundle ] bundlePath ];
NSString* libPath = [ NSBundle pathForResource:@"PerlLibraries" ofType:nil inDirectory:appBundlePath ];
// REVISIT
// CBGetPerlArchver is not being found by the linker, but is found when building a vanilla
// CB project. *shrug*. anyway here’s what it returns in that project:
char* hackyhackhack = “darwin-thread-multi-2level-5.8.6″;
[ CBPerl stubInit:hackyhackhack ];
sp = [ CBPerl sharedPerl ];
The hackyhackhack is the bug I mentioned: apparently CBGetPerlArchVer is available in version 1.0, so such machine-specific ugliness is no longer necessary.
Using the interpreter is then a matter of calling [ CBPerl eval ]:
[ sp useLib:libPath ];
[ sp useModule:@"WWW::Wikipedia" ];
// make the wiki object once
[ sp eval:@"$wikiObj = WWW::Wikipedia->new(); $wikiObj->timeout( 2 );" ];
Now, getting results out of CamelBones-land was another problem for me. I don’t remember the details, but for some reason I wound up using [ CBPerl varAsString ] exclusively. This was fine for my purposes but obviously has its limitations. It may be that I wasn’t using CB correctly, or that there were other bugs, that may have since been ironed out.
I ought to revisit this in light of the new version of CamelBones.