Log file Viewer

[18:47:57] <benji> I have strong opinions about other people's text editors too; their editor should be powerful and they should use it well.

[18:48:29] <aclark> hah

[18:48:35] <papna> benji: So no emacs.

[18:48:45] <benji> heh

[18:48:46] <MattBowen> hahaha

[18:49:24] <MattBowen> yeah i always figured trying something other than emacs couldn't make me less popular

[18:51:35] <benji> I've thought of writing an editor olympics that challenged people to see how much time it takes for them to do common tasks, the first one would be: there is a Python traceback in a terminal window, you want to look at one of the files listed in it but don't have the file open, how long does it take for you to open the file and find the line number given

[18:51:57] <MattBowen> that'd be cool

[18:52:13] <MattBowen> a way of getting a sense about whether the good editors are really that different for skilled users

[19:15:09] <hazmat> J1m, how are you liking zookeeper?

[19:17:05] <J1m> hazmat, I'm very hopeful.

[19:17:31] <hazmat> J1m, awesome.. the bindings have some rough spots, but its been pretty nice

[19:18:01] <J1m> Which bindings are you refering to? The low-level extension that comes w the zk source?

[19:18:03] <hazmat> J1m, one thing i didn't do till relatively late in the game, but that would have nice to do earlier is testing around session expiration and transient connection failures

[19:18:15] <hazmat> J1m, i constructed my own on top of it, txzookeeper

[19:18:19] <hazmat> lots of test coverage

[19:18:31] <hazmat> and most of the cookbook recipes implemented

[19:18:40] <hazmat> http://launchpad.net/txzookeeper

[19:18:46] <hazmat> its twisted though

[19:19:02] <J1m> Yeah, I saw that, but couldn't find documentation and .... twisted :)

[19:19:07] <hazmat> ;-)

[19:19:33] <J1m> Have you seen the stuff I've been working on?

[19:19:49] <hazmat> i've been meaning to put together an eventlet/gevent interface, but lack of free time.. i talked to someone on the eventlet list who put together a prototype.. just pipe writes from the callback thread to get back to the main app thread

[19:20:02] <hazmat> J1m, sidnei pointed it out to me yesterday, i just a had a cursory look

[19:20:43] <J1m> My main goal is having services and consumers find each other and stay connected.

[19:20:46] <hazmat> looks like basic coordination around servers and pipes, with a propertysheet style interface on node objects representing domain services

[19:21:00] <hazmat> s/pipes/apps

[19:21:08] <J1m> right

[19:21:28] <J1m> I had no temptation to use any async library.

[19:22:23] <J1m> I'm also getting jazzed about the idea of modeling a high-level system architecture around a tree.

[19:22:33] <hazmat> cool

[19:22:45] <hazmat> they recently added multi-node transaction support, its not exposed in the python bindings though

[19:22:51] <hazmat> the c library has support though

[19:23:01] <J1m> oooh, that could be very nice.

[19:23:11] <hazmat> else you end up having to keep an index node to coordinate around multi-node changes

[19:23:18] <hazmat> that you want perceived atomically

[19:24:09] <J1m> I don't think anything we're doing in the near term is going to be sensitive to that.

[19:24:43] <hazmat> J1m, also i'd be careful about doing anything long running in the callback thread, its for all of the watches, so any delays, delay all subsequent watch notification

[19:25:11] <J1m> Yeah, I figured as much.

[19:25:45] <J1m> Again, I think our usage will be pretty lightweight.

[19:25:52] <hazmat> cool, most zk usages are

[19:25:54] <hazmat> i'm scheduled to do a talk at the hadoop dc meetup sometime in spring

[19:26:21] <hazmat> i think juju is probably one of the larger apps extant i've seen in terms of model complexity directly in zk

[19:26:24] <J1m> cool, pls let me know when that is, as I'm not in that meetup.

[19:26:30] <hazmat> J1m, will do

[19:26:52] <J1m> which thread mechanics were you concerned with? Thread-safety of callbacks?

[19:27:00] <hazmat> J1m, as an alternative.. but with some drawbacks.. the heroku guys put out doozerd

[19:27:27] <hazmat> its a bit like zk

[19:28:05] <J1m> Does it have something like ephemeral nodes?

[19:28:12] <hazmat> in terms of global ordering etc, without all the java ;-) but it lacks some of the exact same feature set, its an 80/20 solution

[19:28:16] <J1m> To me, that's the big win w zk.

[19:30:17] <hazmat> J1m, it doesn't do ephemerals, and indeed that is a big win, esp for supervision trees, but it can be emulated with watches and heartbeat writes

[19:41:01] <kennethreitz> j00bar: good news, i was able to replicate that bug ;)

[19:41:11] <kennethreitz> just not repetitively

[19:44:36] <j00bar> lol

[19:44:47] <j00bar> i spent five hours yesterday digging into kombu tracking down a bug

[19:48:00] <kennethreitz> hah, nice

[19:48:07] <kennethreitz> using that instead of redis now?

[19:52:35] <j00bar> no - kombu talks to redis

[19:52:42] <j00bar> celery -> kombu -> redis

[19:52:56] <j00bar> we do a lot of chords - makes a lot of sense if you're using chords and celery to use redis

[19:54:42] <j00bar> this is what i ended up with: https://github.com/ask/kombu/issues/86

[20:42:26] <aclark> wtf is kombu?

[20:42:33] <aclark> !google kombu

[20:42:33] <pmxbot> http://en.wikipedia.org/wiki/Kombu - Kombu - Wikipedia, the free encyclopedia

[20:46:14] <hazmat> its the transport abstraction layer under celery

[20:49:05] <djbpython1> that is an interesting bug