10:09:44 <LambdaDusk> acid state without persistence would just be an MVar, right?
10:14:06 <donri> tvar, perhaps
10:15:05 <donri> there is two memory backends, useful for testing
10:38:57 <LambdaDusk> donri: I rather explore options for the user lists for a chatroom etc
10:47:05 <Lemmih> LambdaDusk: Yes.
11:01:22 <LambdaDusk> and it seems like I better write an alternative to happstack-clientsession, one that actually works
11:27:03 <donri> or tell us what problems you're having with it?
11:27:41 <LambdaDusk> for one, it has a strict dependency on happstack 7.0.*
11:30:00 <donri> that's an easy fix
11:30:42 <LambdaDusk> then I have to see, the version I used before had a big problem with the Trans monad, it just never fit into the other transformers I had and needed
11:31:06 <LambdaDusk> the docs that are online are outdated, too, as it seems
11:31:59 <donri> trans monad?
11:33:40 <LambdaDusk> ClientSessionT
11:33:52 <LambdaDusk> and MonadClientSession
11:34:35 <LambdaDusk> it looks fine on the docs but when applied to existing transformer stacks there were problems
11:34:40 <donri> it should fit, but you might need to write some instances by hand...
11:34:41 <LambdaDusk> dang it I lost the code
11:35:33 <donri> it may depend on how you stack the monads
11:36:14 <donri> hm, no, right, if you're using it with hsx you currently have to write the hsx instances by hand
11:36:17 <LambdaDusk> I tried some ways
11:36:23 <LambdaDusk> sorry can't find the code any more
11:37:18 <donri> actually... might work with routet on the outside
11:37:34 <donri> RouteT (ClientSessionT (ServerPartT ...))
11:38:36 <donri> clientsession has to envelope serverpart, but web-routes-hsx provides its own hsx instances that don't rely on serverpart
11:39:02 <LambdaDusk> yes, it was RouteT that was troublesome
11:39:04 <LambdaDusk> I think
11:39:32 <LambdaDusk> I wanted to work with happstack-foundation there because it turned out to be impossible to set up HSX without it for me
11:39:37 <LambdaDusk> huh
11:39:44 <donri> yea hsx is a bit of a mess
11:40:04 <donri> and i'm hoping we can get clientsession set up in foundation so it just works
11:40:12 <LambdaDusk> this is when you have to stop working on stuff for two months and then return to it
11:40:20 <LambdaDusk> that would be great
11:48:10 <LambdaDusk> I wonder if a TH-based HSP-lib wouldn't be a lot cleaner
11:49:07 <donri> there is a plan for TH that generates the instances for a type
11:49:18 <donri> and the new version of hsx has a QQ, if that's what you meant
11:51:37 <LambdaDusk> yes that's what I meant
12:14:00 <LambdaDusk> is there still active work on happstack-foundation?
12:30:12 <LambdaDusk> donri: How would you extend the FoundationT with a Clientsession?
12:31:11 <donri> by adding the necessary instances to foundation
12:41:05 <LambdaDusk> right
15:34:39 <LambdaDusk> my idea is to turn the request-state thingie in foundation to a session-state
15:40:47 <donri> that won't be efficient
15:41:09 <donri> the cookie is heavily encrypted, so we want to minimize reading and writing it
15:51:57 <LambdaDusk> donri that is why it is a session state - you can use "getSessionData" and thus only de-crypt it on demand
15:52:12 <LambdaDusk> donri: the SessionData type would be like Maybe TheData
15:52:49 <LambdaDusk> donri: Nothing means it's not been read yet, and if you do a getSessionData and the state is Nothing, it loads the cookie and caches it for later
15:54:01 <donri> and putting?
15:54:23 <donri> if it is Just a, it might still not have changed
15:54:34 <donri> so you need to track that as well, and at that point you have happstack-clientsession :p
15:54:46 <LambdaDusk> Indeed
15:54:55 <LambdaDusk> I didn't say I didn't wanna use it
15:55:16 <LambdaDusk> I just though that would be the way to incorporate it into Foundation
15:55:44 <LambdaDusk> though that would lack a way to change the session store module
15:55:45 <donri> nah the way we'd do it is add it to the stack and hand-write the missing instances if needed
15:56:09 <donri> but i'm not sure that is needed if you're using RouteT on top ...
16:00:42 <LambdaDusk> well ok then do that
16:00:46 <LambdaDusk> I will sit here and wait
16:01:36 <stepkut> someone patched the pasteboard example to include happstack-authenticate
16:02:02 <stepkut> I should apply that patch and push it or something :)
16:04:24 <LambdaDusk> happstack-authenticate? jeez
16:04:45 <LambdaDusk> at least put up a proper link on the happstack documentation site ^^
16:04:57 <stepkut> link to ?
16:05:13 <LambdaDusk> foundation and the ControlV example
16:05:25 <stepkut> k
16:08:20 <LambdaDusk> and happstack-authenticate ^
16:08:40 <LambdaDusk> is it an authenticate wrapper?
16:36:26 <stepcut> yes, though more than just a wrapper
16:37:24 <stepcut> authenticate basically just does the openid calls, you still need to do a bunch more stuff to actually have an authentication library
16:40:42 <stepcut> ok, so one problem with the current FoundationT type might be that it only gives you control over the monad inside ServerPartT, but sometimes you need a monad transformer on the outside
16:41:19 <stepcut> another issue is that HSP cares what your outermost monad is
16:41:29 <LambdaDusk> yes it does
16:42:49 <stepcut> to help with outermost monad transformer issue, we are introducing a new monad HSPT in the upcoming release of HSP. Its a monad transformer that does nothing but make HSP happy
16:43:03 <stepcut> so it can live on the outside of everything
16:43:24 <stepcut> of course, it will need MonadRoute and Happstack instances, but we can provide that is well
16:43:56 <stepcut> but, you still need a way to add monad transformers to the stack
16:44:51 <stepcut> perhaps we want to change the type to: type FoundationT' url acidState requestState m = HSPT XML m (RouteT url (StateT (AppState url acidState requestState) (ServerPartT IO))
16:45:31 <stepcut> so that the user supplied monad transformer can access everything below itself in the stack?
16:48:36 <stepcut> oo, this example shows how to add happstack-clientession to controlV not happstack-authentication :)
16:48:42 <stepcut> it's also not pretty :-/
16:50:38 <LambdaDusk> maybe the entire stack has to be re-thought for Happstack 8?
16:50:42 <stepcut> oh how nice, I patched happstack-foundation to fix the bounds issue, but apparently never run cabal upload on it
16:50:52 <LambdaDusk> nice
16:51:25 <stepcut> LambdaDusk: we are certainly willing to change it.. first someone needs some suggestions on what / how to change it
16:52:01 <stepcut> oh, I take it back, the patched version is already uploaded
16:52:03 <stepcut> http://hackage.haskell.org/package/happstack-foundation-0.2.3
16:52:15 <LambdaDusk> well I always liked the flexibility... ut there's a reason why yesod and snap have the entire thing as one piece
16:52:44 <stepcut> right, that is the idea behind happstack-foundation.. make something that is one piece :)
16:53:31 <stepcut> but, it is also new, so it has some short comings were we lost too much flexibility
16:53:54 <stepcut> which is one of the reasons why I have not pushed it too heavily yet (also it is not fully documented either)
16:55:24 <stepcut> the real issue with HSP is that it uses type families, so you can't use newtype deriving to automatically lift its instances to the outermost monad
16:56:01 <stepcut> we have thought about writing some TH code that would do what the GeneralizedNewtypeDeriving can't do for us
17:00:39 <stepcut> I am patching up the clientsession example and will commit it in a minute
17:08:04 <stepcut> it would be nice to find a better way of gluing things together besides monad transformers
17:08:22 <LambdaDusk> Arrows?
17:08:37 <stepcut> >:(
17:09:05 <LambdaDusk> what?
17:09:13 <LambdaDusk> you asked and I answered
17:09:19 <stepcut> how would that work?
17:09:37 <LambdaDusk> Haskell On A Horse even put the entire session state into an automaton arrow
17:10:01 <LambdaDusk> it would be highly inefficient regarding memory use, but a cool way to make it stateful
17:10:05 <stepcut> I have no issue with Arrows.. but I don't see how that helps us build independent pieces that you can glue together
17:10:55 <LambdaDusk> hmm
17:10:57 <stepcut> in fact, there are some places I would like to add arrows in happstack
17:16:50 <stepcut> hmm, this code does not compile, and it contains an undefined that seems like it would cause it to fail if it did
17:17:24 <stepcut> maybe the undefined is ok
17:17:50 <stepcut> hmm. no..
17:27:06 <LambdaDusk> which doesn't?
17:38:08 <stepcut> someone sent code which is supposed to integrate happstack-clientsession support into the ControlV example.. but it doesn't compile
17:42:04 <stepcut> I also have no idea where this code came from ...
18:44:29 <Palmik> stepcut, what about the records-as-typeclass approach? I think you have discussed here some time ago.
18:54:18 <stepkut> Palmik: what about it ?
18:56:32 <Palmik> Hmm, I probably misunderstood what you were talking about -- I though we are talking about some sort of module (for happstack) system.
18:57:35 <stepcut> I was saying it would be nice if you could build independent pieces like happstack-authenticate happstack-clientsession, etc, and then allow the user to glue those together in their application with out having to build a leaning tower of monads
19:05:29 <Palmik> Hmm, that. That's one the things I do not like about monads -- they just do not easily compose.