Log file Viewer

[22:05:01] <epicserve> wiredfool_: Dude!

[22:21:53] <wiredfool_> epicserve: hey

[22:25:39] <wiredfool_> please. distract me from mobile browsers

[22:31:20] <epicserve> wiredfool_: I just wanted to say thanks for all the help on the issues I was having.

[22:31:51] <wiredfool_> got it all working?

[22:38:49] <epicserve> mostly

[22:38:56] <epicserve> wiredfool_: check this out, https://gist.github.com/epicserve/50775c7111caec6512b8

[22:39:10] <epicserve> That's a conversation I just had in #boto

[22:40:10] <wiredfool_> hah

[22:40:51] <wiredfool_> saw that, though I think preload_metadata was false

[22:41:51] <wiredfool_> though, that was only the defaults, I didn't track that down farther

[22:43:30] <wiredfool_> fwiw, you can use an offset in the boto list command, so by a basic binary search, you can keep offsetting up till you run out of items

[22:44:32] <epicserve> wiredfool_: that would be faster … but still slow.

[22:44:58] <wiredfool_> it's only log(n)

[22:45:16] <wiredfool_> granted each one is a ssl request

[22:45:36] <epicserve> my point is why use exists() at all if you don't have to

[22:45:59] <wiredfool_> so, if you take that check out, does it just use normal amounts of memory?

[22:46:11] <epicserve> yes

[22:46:23] <wiredfool_> actually, there are very good reasons for not using exists first.

[22:46:31] <wiredfool_> apart from your bug

[22:46:39] <epicserve> I'm using my patch now on the server

[22:47:08] <epicserve> and the processes is holding steady at 167M

[22:47:18] <wiredfool_> that sounds like victory

[22:47:56] <wiredfool_> I sonder what self.bucket.new_key is doing in the background

[22:48:56] <wiredfool_> nothing expensive

[22:49:40] <wiredfool_> so, anyway. If you check for exists(), it's a race condition

[22:50:13] <wiredfool_> granted, there's still a race condition on the delete

[22:50:32] <wiredfool_> actually, I think you might not even need to delete first with the s3 backend

[22:51:56] <wiredfool_> anyway. victory is good. And I'm really liking dtrace & python

[22:52:35] <epicserve> Do you normally work on a OSX box?

[22:52:46] <wiredfool_> I think it's possible to pull integrated python + c backtraces using dtrace, where you get file+line+function data for pyhon code, and the normal info from c

[22:52:50] <wiredfool_> epicserve: no.

[22:53:17] <wiredfool_> used to, and have one on the desk, but I switched to linux a year or more ago

[22:55:17] <wiredfool_> right after a hard drive died and while time machine was freaking out by deleting and recreating a backup.

[22:55:18] <epicserve> wiredfool_: what hardware do you use on your linux box and what distro?

[22:56:00] <wiredfool_> I've got an i7, in a silent case with a ton of drives, running xubuntu 12.04

[22:56:36] <wiredfool_> though, when I was on the mac, I was doing most of the dev work using emacs on an adjacent linux box

[22:56:49] <wiredfool_> so, now, I'm using emacs against a virtual machine

[22:57:06] <wiredfool_> almost all my work is done in virtual machines

[22:57:33] <epicserve> virtualbox?

[22:57:37] <wiredfool_> kvm

[22:57:53] <wiredfool_> which is what I'm running on the servers