00:00:00 <stepcut> hmm 00:00:28 <stepcut> maybe we should make something like IxSet that is useful as a lens? 00:00:52 <donri> yea, it's something to keep in mind for the future ixset 00:01:11 <donri> i think it coincides anyway with my desire for unique indices and all that 00:01:31 <donri> that is the problem, really, the ambiguity of an index not resolving to a single entry 00:02:11 <stepcut> right 00:02:18 <stepcut> unique indices and auto-increment would be very nice 00:02:37 <donri> and disk-serialized values or in-memory compression 00:02:50 <donri> and type safe queries 00:03:14 <donri> and boolean queries without recalculating indices :) 00:03:46 <stepcut> go for it! 00:03:53 <stepcut> i am working on acid-state this week, btw 00:04:00 <donri> bitonic hinted that higgsset is only a nicer ixset that still suffers from some problem i didn't understand, suggesting kdmap might be better in the end 00:04:07 <stepcut> right now I am fixing the problem where it runs out of file descriptors if you have a lot of checkpoint files 00:05:16 <donri> it scares me that checkpointing can explode the size of your data by reducing sharing 00:06:10 <donri> it means i have to keep that in mind when modeling my data :( part of why acid-state is nice is being more free to model data as you want 00:27:00 <donri> stepcut: future fastirc release has some frp stuff, author says 00:29:27 <stepcut> ooo 00:29:39 <donri> using netwire 4, due next week or so 00:29:44 <donri> fastirc "probably longer" 00:29:44 <stepcut> neat 02:24:34 <donri> stepcut: did you see the new bug, someone having issues with plugins on windows 04:16:41 <stepkut> Lemmih: newestEntry forces all found checkpoints to be openned via openBinaryFile even if only the most recent version is needed because Lazy.readFile is not quite lazy enough. This is lazy enough: 04:16:43 <stepkut> archives <- mapM (unsafeInterleaveIO . Lazy.readFile) files 04:18:17 <stepkut> or I could change 'worker' to be: worker :: [FilePath] -> IO (Maybe object), and then only do the readFiles as needed. Or even better, bracket an explicit open/close to ensure that things really get closed .. 04:18:23 <stepkut> Lemmih: any preferences ? 04:18:30 <stepkut> ACTION votes for the latter 04:19:05 <donri> needs moar pipes 04:19:39 <stepkut> :) 04:19:48 <stepkut> step 1. wait for pipes to have exception handling 04:19:52 <donri> yea 04:20:13 <stepkut> do the mirrored lenses change anything that would be useful for IxSet ? 04:20:17 <stepkut> http://comonad.com/reader/2012/mirrored-lenses/ 04:23:49 <donri> maybe, not sure 04:23:49 <donri> there's also multilenses in data-lens HEAD 04:24:48 <stepkut> ooo 04:30:44 <donri> bedtime! 04:30:50 <stepkut> me too soon 11:44:29 <Lemmih> stepkut: Sounds good. Where's the patch? 14:16:19 <stepkut> Lemmih: which way sounds good? The one that uses unsafeInterleaveIO, or the one that modifies worker to use IO ? 15:34:28 <donri> stepcut: so, do updates block queries? 15:34:31 <donri> re #snapframework 15:35:57 <stepkut> donri: dunno. Lemmih said we should pester him if informaton like that is not clear from the docs 15:39:11 <donri> well, "update" blocks until changes are durable, but that doesn't tell you what it does from different threads 15:39:38 <stepkut> right 15:40:01 <stepkut> I agree that updates should not block queries from other threads, just not clear if that is how the actual implementation works 15:40:53 <donri> well if that is the case, sopvop would have the same problem with acid-state as with mongo 15:40:57 <donri> not sure that's wrong, though 15:41:11 <stepkut> why would he have the same problem ? 15:42:00 <donri> guess that depends on if by "same client" he means same thread or not 15:42:25 <stepkut> that would be important to know 15:42:36 <stepkut> but, even then, it should not be a problem 15:43:05 <donri> well if it's from different threads, it could be? 15:43:39 <donri> oh wait he's actually waiting for the transaction to "finish" 15:43:42 <stepkut> if you have two threads and the second thread is supposed to do a query after the first thread has performed the update.. clearly you need some synchronization method.. like a QSem that the first thread writes after the update returns. 15:44:04 <stepkut> Once that update has returned, any query events issued will get the updated value 15:44:30 <donri> so even if this is separate requests, probably the second results from a redirect after the first has finished the update 15:44:51 <stepkut> sure 15:45:20 <stepkut> any time you call the query function after the update has returned you should get only the updated value 15:45:34 <donri> yea 15:45:44 <donri> i was neglecting to consider the "has returned" part :) 15:45:57 <stepkut> right 15:46:18 <donri> also, what happens if an update fails, i guess acid-state throws some error and happstack throws a 500? 15:46:21 <stepkut> the question is what happens while the transaction is runnng. Either we can block and not permit any queries to run, or we can let them run on value before the update 15:46:36 <stepkut> http://acid-state.seize.it/Error%20Scenarios 15:47:26 <stepkut> what are ways an update can 'fail'. It can raise an exception ? 15:47:54 <stepkut> either intentionally, or by failing to match patterns, etc 15:48:14 <Lemmih> donri: Updates do not block queries. 15:48:33 <donri> makes sense 15:49:38 <donri> stepkut: duno, like, disk runs out of space, log directory is made read-only or changes owner... 15:49:42 <Lemmih> stepkut: Serializing its arguments can also fail. 15:50:48 <donri> i guess in part i'm used to dealing with SQL and ORMs in dynamic languages where you need to check if a "save" operation succeeded because you might pass it the wrong types or data not passing validation, but such things are handled with types in haskell and reform 15:50:49 <stepkut> in all cases, those things get turned into an exception which gets returned caller of update/query? 15:50:58 <donri> but i guess errors can still happen at runtime with acid-state 15:51:06 <donri> and i'm also wondering how we deal with errors in happstack in general 15:51:13 <Lemmih> stepkut: No. :D 15:51:22 <stepkut> :D 15:51:28 <donri> often, an error response other than 500 will be more suitable 15:51:46 <Lemmih> stepkut: I wish it worked that well. I think it's the biggest misfeature in acid-state right now. 15:51:54 <stepkut> Lemmih: :) 15:52:43 <stepkut> donri: that is left up to the user.. You can use ErrorT and http://www.happstack.com/docs/happstack-server-7.0.2/doc/html/happstack-server/Happstack-Server-Error.html 15:52:51 <Lemmih> I was like "Oh, I should totally fix that" and then I realized how fucking difficult it would be with the way I've structured the beast. 15:53:03 <stepkut> donri: and we also provide monad-control instances 15:53:07 <Lemmih> I'll get it right in the next rewrite. 15:53:11 <stepkut> Lemmih: k 15:53:48 <Lemmih> Exceptions are /mostly/ given to the caller of the update/query. 15:55:30 <donri> i want an acidServer and an openLocalState at the same time, for the same state 15:56:17 <stepkut> donri: isn't that how it is always done? 15:56:47 <stepkut> donri: acidServer takes AcidState handle as its argument.. 15:56:55 <donri> well I want to use openLocalState internally in the app but also expose it as an acidServer for remote control / ghci etc 15:57:11 <donri> aha! 15:57:21 <donri> i misread AcidState as IsAcidic 15:57:28 <stepkut> donri: :) 15:57:39 <donri> nice 15:57:43 <stepkut> donri: what you are wanting to do is pretty much the exact reason it was created :) 15:58:16 <donri> well i thought the way you did it was openRemoteState to yourself 15:58:24 <donri> hm deja-vu, have we discussed this before? 15:59:19 <stepkut> not that I remember 15:59:21 <donri> + i thought the main purpose of the remote backend was to allow separate db server 16:00:11 <stepkut> donri: its good for that too.. 16:00:15 <donri> :) 16:08:26 <stepkut> Lemmih: should I send the patches to your gmail account? 17:10:49 <donri> hm, how do you secure an acidServer on a shared host 17:10:58 <donri> i guess UnixSocket? 17:12:14 <stepkut> yeah 17:14:00 <stepkut> though, I think acidServer needs a bit of refactoring so that you can setup a socket connection, do authentication, encrypt it with SSL, etc, and then just pass something generic to acidServer to work with 17:14:17 <stepkut> like a Handle that it can read/write.. with out having to know about any of that other stuff 20:49:17 <Lemmih> stepkut: Or just use an SSH tunnel. 20:50:26 <stepkut> Lemmih: well, right now I think acidServer listens on all interfaces on the port #, so..