16:47:09 <luite> are there any plans for a multimaster distributed acid-state?
16:50:12 <stepkut> luite: yes.. there is even a little code
16:50:50 <stepkut> Data.Acid.Replication. Though I don't think it is useable yet
16:51:36 <luite> any documentation on the algorithms for synchronization and locking?
17:08:13 <stepkut> luite: not yet. Lemmih is still working on the ideas
17:09:59 <stepkut> CPS style coding makes my head hurt
17:10:11 <stepkut> making cereal lazy sure is tricky
17:10:33 <stepkut> one problem is that with a function like:
17:10:34 <stepkut> getLazyByteString :: Int64 -> Get L.ByteString
17:10:49 <stepkut> you have to start return values before you know if you are actually going to be able to get 'n' bytes
17:11:17 <stepkut> or you have to force 'n' bytes into RAM.. which is what I am trying to avoid
18:00:43 <stepkut> seems like the solution might be to use runGetState to read a chunk at a time
18:00:57 <stepkut> that could also allow use to check the crc16 as we go
18:01:05 <stepkut> we won't know if it was valid until the very end.. but that is ok
18:01:23 <stepkut> we assume that everything is cool and do all the work , and then abort at the last second when something is screwy
18:04:20 <luite> hmm, are those things related to a distributed acid-state? i'm not sure i understand the problem :)
18:04:31 <stepcut> nope
18:04:41 <stepcut> they are related to acid-state using more RAM than it should
18:04:46 <luite> oh!
18:05:07 <stepcut> that's what I am looking into these days
18:05:09 <luite> yeah i see now, i wondered why that would be a problem with distributed stuff but not with a local acid state :)
18:05:15 <stepcut> :)
18:05:32 <stepcut> it's actually related though
18:05:47 <stepcut> because we use cereal to send data over the network
18:05:49 <luite>  i'm looking into collaborative editing, for shaprs gsoc project
18:06:01 <donri> this is operation make hackage2 feasible
18:06:08 <stepcut> so, for example, when you get the initial copy of the state, it means you would have to wait for the whole thing to arrive instead of decoding it as it comes of the wire
18:06:22 <stepcut> donri: yes. Among other things
18:07:14 <luite> stepkut: it could make responses a bit faster, but i think you want to have the full state anyway?
18:07:58 <stepcut> yes, but you don't want to have to load the entire state + the entire checkpoint into RAM at once
18:10:08 <luite> oh aren't checkpoints usually smal?
18:11:17 <stepcut> luite: well. they contain your entire state.. usually the binary format is a lot more compact than when you decode it, but.. it can still be sizeable
18:12:24 <stepcut> if you state is mostly ByteStrings, then the checkpoint could be almost as big as the unpacked state
18:14:30 <luite> oh right, i thought the checkpoint was just the updates
18:16:53 <stepcut> yeah, the events will generally be small
18:17:05 <stepcut> and if they are not.. you might want to reconsider what you are doing :P
20:39:59 <stepcut> rust: http://i.imgur.com/OdYxZ.jpg  or no rust: http://i.imgur.com/hNqSU.png
21:23:13 <donri> difficult to read with rust
21:24:01 <donri> plus it looks more like dirt :)
21:37:54 <stepkut> the font needs to be bigger for sure
21:37:59 <stepkut> no matter what
21:38:07 <stepkut> I'll work on the rustiness more