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.