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..