00:19:49  * chapelquit (Read error: Operation timed out)
00:23:08  * werlequit (Quit: Leaving.)
00:25:01  <rvagg>Node 0.11 Buffer changes are looking interesting; we might be able to squeeze greater performance out of Buffer passing by completely avoiding another memcpy on the way of LevelDB to V8
00:27:06  * no9quit (Ping timeout: 264 seconds)
00:47:10  * timoxleyquit (Quit: Computer has gone to sleep.)
00:49:06  * chapeljoined
00:56:55  * ralphtheninjaquit (Ping timeout: 264 seconds)
00:57:03  * ralphtheninjajoined
01:16:15  * timoxleyjoined
02:24:56  * timoxleyquit (Quit: Computer has gone to sleep.)
02:25:22  * ralphtheninjaquit (Ping timeout: 276 seconds)
02:38:23  * chapelquit (Read error: Operation timed out)
02:41:18  * CPartridgechanged nick to ChrisPartridge
02:51:31  * chapeljoined
03:11:19  * owen1quit (Ping timeout: 264 seconds)
03:26:00  * owen1joined
04:11:24  * timoxleyjoined
04:29:59  * timoxleyquit (Quit: Computer has gone to sleep.)
04:31:16  * timoxleyjoined
05:33:20  * timoxleyquit (Quit: Textual IRC Client: www.textualapp.com)
05:33:50  * brianloveswords_quit (Excess Flood)
05:34:44  * brianloveswordsjoined
07:07:10  * Pwnnajoined
07:16:19  * Pwnnaquit (Ping timeout: 245 seconds)
07:26:42  * no9joined
07:33:35  <juliangruber>rvagg: I've heard about that too, that will be the missing link between buffer and string performance
07:51:43  * chapelquit (Ping timeout: 260 seconds)
07:53:59  * chapeljoined
08:01:05  * dominictarrquit (Quit: dominictarr)
08:23:58  * no9quit (Read error: Operation timed out)
08:24:26  * ralphtheninjajoined
08:45:41  * mcollinajoined
08:55:02  * ChrisPartridgequit (Ping timeout: 252 seconds)
09:26:00  * mcollinaquit (Remote host closed the connection)
09:45:57  * mcollinajoined
10:13:39  * dominictarrjoined
10:20:10  * dominictarrquit (Ping timeout: 256 seconds)
10:49:47  * mcollina_joined
10:53:17  * mcollinaquit (Ping timeout: 252 seconds)
10:54:59  * missinglinkjoined
10:55:16  * missinglinkpart
14:25:32  * werlejoined
17:04:36  * werlequit (Read error: Connection reset by peer)
17:04:42  * werle1joined
17:16:39  * st_lukejoined
17:31:55  * brianloveswordsquit (Excess Flood)
17:33:48  * brianloveswordsjoined
19:02:59  * mcollina_quit (Ping timeout: 245 seconds)
19:35:33  * ralphtheninjaquit (Ping timeout: 248 seconds)
19:42:44  * weetabeexquit (*.net *.split)
19:44:01  * ralphtheninjajoined
19:45:14  * ralphtheninjaquit (Client Quit)
19:50:00  * weetabeexjoined
19:51:53  * dominictarrjoined
20:05:36  * werle1quit (Quit: Leaving.)
20:06:00  * werlejoined
20:43:54  * weetabeexquit (Ping timeout: 264 seconds)
22:36:14  * ralphtheninjajoined
23:13:50  * brianloveswordsquit (Excess Flood)
23:15:17  * brianloveswordsjoined
23:17:08  * werlequit (Quit: Leaving.)
23:35:00  <Raynos>idea!
23:35:07  <Raynos>Implement redis API on top of leveldb
23:46:56  * CPartridgejoined
23:47:20  <chilts>that'll be interesting ... Redis can do atomic things like 'inc' but with leveldb you'd have to read it out and write it back (possible reads in the middle)
23:47:30  <chilts>or we just do the API and the write to disk when we know it's correct?
23:47:34  * werlejoined
23:47:44  <chilts>e.g. inc in memory then write it at intervals?
23:48:05  <chilts>same with things like sets and other types
23:49:29  <chilts>I think it would end up being something like Redis in Node.js, with LevelDB as the persistance
23:49:34  <chilts>Raynos: ^^ thoughts?
23:50:14  * CPartridgechanged nick to ChrisPartridge
23:51:33  <Raynos>chilts: fuck atomic things
23:51:58  <Raynos>but you make a good point
23:52:04  <Raynos>sounds like I should give up on this idea
23:52:27  <chilts>nah, it's an interesting one :)
23:53:33  <chilts>Raynos: I'm also using LevelDB for a kind of distributed store where all changes to items are cumulative (e.g. inc: 1) and then you can 'collapse' the changesets occassionally
23:53:39  <chilts>seems to work quite well so far
23:53:48  <chilts>(as yet unfinished)
23:54:03  <rvagg>inc isn't a problem since a single JS thread is the gateway to leveldb so you can handle conflicting writes in between
23:54:04  <chilts>so yeah, it's not atomic but just keeps a list of changes for each item
23:54:27  <chilts>rvagg: how do you deal with that in your JS code though?
23:54:31  <rvagg>you just need to do a bit of caching and checking--but redis does that anyway
23:55:01  <rvagg>chilts: you just need to intercept writes
23:55:14  <chilts>ah, there was another module that did that, right?
23:55:25  <rvagg>there's a couple that are dealing with this now I think
23:55:49  <chilts>so they're sequentially done in exactly the same order as .get(), .put() and .batch()?
23:56:03  <chilts>as-in, in the same order you call all of those things
23:56:48  <rvagg>not quite, there's no guarantees there but you just need to add some data structures to your js and do some checking as you intercept those calls
23:57:14  <chilts>ok
23:57:36  <rvagg>BUT, if you're doing a put('foo', 100) just after an inc('foo') what would be the expected behaviour? it should go to 100 regardless eh?
23:57:46  <rvagg>so all you really need to care about is a protected inc()
23:58:04  * werlequit (Quit: Leaving.)
23:58:06  <rvagg>where multiple calls to the same key before internal leveldb callbacks return do the right thing
23:58:25  <rvagg>so just a bit of memory to store in-flight increments and a bit of checking to see if the key being incremented is in-flight
23:58:35  <chilts>right, cool
23:59:25  <rvagg>having said that, my suspicion is that most devs use atomicity as a crutch to avoid having to think and that much of the time people are doing atomic operations they are not actually needed
23:59:29  <rvagg>but devs do love their crutches