Facebook support for BarnOwl : ezyang’s blog

Facebook support for BarnOwl

This one's for the MIT crowd. This morning, I finished my Facebook module for BarnOwl to my satisfaction (my satisfaction being asynchronous support for Facebook API calls, i.e. no more random freezing!) Getting it to run on Linerva was a bit involved, however, so here is the recipe.

Setup a local CPAN installation using the instructions at sipb.mit.edu, using local::lib. Don’t forget to add the setup code to .bashrc.mine, not .bashrc, and then source them. Don't forget to follow prerequisites: otherwise, CPAN will give a lot of prompts.
Install all of the CPAN dependencies you need. For the Facebook module, this means Facebook::Graph and AnyEvent::HTTP. I suggest using notest, since Any::Moose seems to fail a harmless test on Linerva. Facebook::Graph fails several tests, but don't worry about it since we'll be using a pre-packaged version. If you want to use other modules, you will need to install them in CPAN as well.
Clone BarnOwl to a local directory (git clone git://github.com/ezyang/barnowl.git barnowl), ./autogen.sh, configure and make.
Run using ./barnowl, and then type the command :facebook-auth and follow the instructions!

Happy Facebooking!

Postscript. I am really, really surprised that there is not a popular imperative language that has green threads and pre-emptive scheduling, allowing you to actually write code that looks blocking, although it uses an event loop under the hood. Maybe it’s because being safe while being pre-emptive is hard...

Known bugs. Read/write authentication bug has been fixed. We seem to be tickling some bugs in BarnOwl's event loop implementation, which is causing crashing on the order of day (making it tough to debug). Keep a backup instance of BarnOwl handy.

Ben says:

July 13, 2011 at 9:33 am

Hi Edward,

Regarding your postscript – python has eventlet and gevent that let you write code that looks blocking but utilizes green threads and an eventloop. Have you seen them?

Ben

lumi says:

July 13, 2011 at 10:35 am

Have you looked at Perl’s Coro, and Coro::AnyEvent?

Edward Z. Yang says:

July 13, 2011 at 10:40 am

My impression of libraries that are strapped on top of an existing language ecosystem is that they really, really don’t play nice with existing code (but I’ll happily be proven wrong on this point.) The end result is you have to think very carefully about whether or not code you use is interoperable with what effectively is a new runtime system.

July 13, 2011 at 10:55 am

My experience with eventlet has been very positive so far! Everything (apart from C extensions) just magically becomes non blocking, but is still imperative and easy to reason about.

July 13, 2011 at 11:12 am

Looks like they use monkeypatching to make things work. It is worth remarking that these are cooperative threading libraries, so you have to remember where you might lose control, and where you have to explicitly yield.

Brian says:

July 14, 2011 at 10:24 am

Haskell: popular, imperative, green threads, looks blocking, kqueue under the hood.

July 14, 2011 at 10:31 am

Yeah, I certainly wouldn’t throw eventlet at anything CPU intensive, but for any app where you’re just sitting in the middle of lots of IO it’s ideal. I use it in a webapp bridging between websockets and zeromq and it’s ok for that.

July 14, 2011 at 11:19 am

Brian: I was wondering when someone would say that! :-)

Ben: Right. And for unrelated reasons, CPU intensive parallelism doesn’t work anyway (for example, Python and the GIL). I don’t have a sense for how much of a problem this is in practice, but one of my concerns is latency in user interfaces, where even a second processing delay can noticeabley impact user experience.