07:56:18 <LambdaDusk> hello
08:06:44 <donri> ohai
08:14:29 <LambdaDusk> solved any big problems overnight?
08:15:00 <LambdaDusk> halting problem, P=NP, anything?
08:18:06 <donri> :)
08:21:28 <adnam> managed to find out about ghc -fno-code, almost as awesome
08:22:07 <LambdaDusk> adnam: Share the knowledge?
08:23:01 <adnam> http://stackoverflow.com/questions/12373722/make-ghc-only-type-check
08:23:56 <donri> \o/
08:24:22 <LambdaDusk> wow
08:25:28 <donri> in case you're confused, the point of it is to type check fay code
08:26:02 <donri> well, in the context of adnam :)
08:26:37 <LambdaDusk> I am always confused, yeah, but I could have guessed... fay is on my list of stuff to try and figure out - should it be possible
08:34:36 <donri> actually, -fno-code could be useful for IDEs/editors
08:34:44 <donri> make things like syntastic in vim faster
08:34:46 <donri> hm!
08:38:03 <donri> yep, it works
08:43:36 <donri> adnam: https://github.com/kazu-yamamoto/ghc-mod/issues/80 awesome sauce
08:56:08 <LambdaDusk> finally re-compiled everything, call from gran... will I ever get to make this login system?
08:56:39 <LambdaDusk> incidentally, is anyone making an OAuth server system in haskell?
09:16:07 <adnam> donri: :) but i'm an emacser
09:16:17 <donri> adnam: ghc-mod is for emacs too
09:16:21 <donri> flymake or something
09:16:54 <adnam> oh
09:17:48 <adnam> i read the description except for the "Emacs" part :)
09:20:48 <adnam> is it like scion except it works?
09:22:30 <donri> i guess
09:25:50 <adnam> i'll try it, haskell-mode is unstable
09:33:24 <donri> duno if it replaces haskell-mode
09:35:05 <adnam> parts of the newer features i'm guessing
10:39:21 <donri> Lemmih: yea, no, acidServer is just IO (), no handle to close returned
10:39:56 <donri> and acidServer blocks anyway
10:40:25 <donri> although internally, `finally` sClose sock
10:44:08 <donri> doesn't seem to close the handle though, but maybe sClose does that implicitly?
10:45:55 <donri> Lemmih: BTW, are you supposed to be able to createArchive over a remote? the types don't seem to forbid it but that function is defined in Local and the remote Command type doesn't include it
10:47:52 <donri> RemoteClient.hs: Data.Acid: Invalid subtype cast: RemoteState -> LocalState
10:47:55 <donri> guess not!
12:51:58 <Lemmih> donri: Yeah, that's not allowed.
12:52:15 <donri> Lemmih: could be useful though?
12:52:27 <Lemmih> I'm not sure.
12:55:00 <donri> what's the purpose of these dynamic casts btw, why not expose a type safe api?
12:55:15 <LambdaDusk> ok that's it, I am done with haskell and happstack, done, back to node
12:55:20 <donri> lol
12:56:53 <Lemmih> donri: Typing is difficult.
12:56:58 <donri> heh
12:57:33 <LambdaDusk> I am tired of working around errors that shouldn't be there, disassembling spaghetti type stacks, unexpected behaviour of code that is tested before
12:59:01 <donri> unexpected behavior of tested code that type checks?
12:59:34 <donri> expect a ton more of that with node? :p
12:59:54 <LambdaDusk> actually, this specific code always ran smoothly in node
13:00:21 <LambdaDusk> jmacro seems to do something with it and suddenly it causes continuous reloading
13:00:33 <donri> wat
13:02:48 <LambdaDusk> and moreover I have been working on this for over a week and I have the impression I have not gotten a single step forwards
13:04:13 <donri> at least ditch happstack for snap or yesod ;)
13:05:32 <LambdaDusk> yesod and acid-state, I don't know how they'll work... though they should...
13:05:40 <LambdaDusk> snap... hm
13:07:07 <donri> or yesod with persistent? if you just want to get shit done without caring about the code ;)
13:08:05 <LambdaDusk> incidentally I want to have websockets somewhere in the end
13:08:25 <donri> happstack doesn't currently support websockets
13:09:03 <LambdaDusk> I know that
13:09:15 <donri> not directly anyway, duno if you could use the websockets package with happstack-server somehow
13:09:22 <LambdaDusk> forkIO and a websockets server
13:09:39 <donri> sure, different ports
13:10:22 <donri> you did try yesod and snap didn't you? did you decide on happstack after trying all three?
13:10:34 <LambdaDusk> yes
13:11:14 <LambdaDusk> I was hoping for more freedom
13:11:22 <donri> i'd think if type errors scare you you'd prefer snap, and if you want bling you'd prefer yesod
13:12:09 <LambdaDusk> They're not scaring me, I just feel very, very helpless with many of them
13:12:24 <donri> you get used to them and learn to interpret them
13:12:37 <donri> if you already spent weeks with this, maybe most of the pain is over already ;)
13:13:04 <LambdaDusk> but there's still the problem that I can't quite see how jmacro changes my javascript
13:14:04 <donri> show code!
13:14:13 <donri> and explain the problem
13:14:40 <LambdaDusk> grrrr and now I have to interrupt again for hours because I've got to heed a call
13:14:41 <LambdaDusk> sorry
13:14:51 <LambdaDusk> will be here later, perhaps?
13:15:15 <donri> ok :)
13:15:29 <LambdaDusk> thanks
14:13:05 <stepkut> so, the problem with ClientSessionT is that if we stick it on the inside like this:
14:13:06 <stepkut> type CtrlV'    = FoundationT' Route CtrlVState () (ClientSessionT SessionData IO)
14:13:34 <stepkut> then we can't invoke withClientSessionT, because we need access to the Happstack class
14:14:34 <stepkut> if we stick it on the outside, type CtrlV'    = ClientSessionT SessionData (FoundationT' Route CtrlVState () IO), then it screws up HSX, and function in happstack-foundation that expect some of type FoundationT
14:22:55 <donri> I think you can't stick it inside either way because of hsx
14:23:08 <donri> i think?
14:23:35 <stepkut> not sure why hsx wolud be a problem for inside
14:24:47 <donri> oh wait no it would work because foundation gets the hsx instances from web-routes-hsx
14:24:57 <stepkut> right
14:25:26 <stepkut> I am looking to see if I can make withClientSessionT work when the ClientSessionT is inside the ServerPartT
14:27:20 <stepkut> step 1: need mapFoundationT function
14:28:07 <donri> is there any win with these insane mtl issues compared to something like snaplets?
14:28:31 <stepkut> ?
14:28:51 <stepkut> go on
14:28:59 <donri> well all these instances we have to define any time we add something to the stack
14:29:03 <donri> you don't need that with snaplets
14:29:07 <donri> or plain transformers for that matter
14:29:10 <stepkut> how does it work instead?
14:29:21 <donri> i think snaplets is a bit like transformers but instead of explicit lift chains you have explicit lenses
14:29:51 <donri> mtl: ask, transformers: lift . lift $ ask, snaplets: with lensToSomeReader ask
14:30:36 <stepkut> and you think we could implement clientsession using this ?
14:30:51 <donri> duno, but clientsession is a snaplet in snap AFAIK
14:31:26 <stepkut> well.. I don't know either :)
14:31:45 <stepkut> but I would like to
14:34:48 <donri> i wonder if you could define a state monad as a free monad and thereby get the put-tracking for, uh, "free"
14:37:29 <stepkut> http://www.haskellforall.com/2012/07/free-monad-transformers.html
14:37:34 <stepkut> see the 'denotation' section
14:41:00 <donri> hm but that doesn't permit an "interpreter" of state computations?
14:41:59 <stepkut> I didn't really read it, working on this clientsession stuff
14:42:09 <donri> ok :)
15:51:48 <stepkut> ok.. it is possible to rejigger withClientSessionT so that the ClientSessionT can be instead the ServerPartT.. but it is pointless because functions like getSession require that ClientSessionT be outside of the ServerPartT
15:52:27 <stepkut> we could perhaps reformulate FoundationT as
15:52:29 <stepkut> type FoundationT' url acidState requestState t = XMLT (RouteT url (t (StateT (AppState url acidState requestState) (ServerPartT IO))))
15:52:46 <stepkut> so that you can still your monad transformer outside of ServerPartT
15:53:12 <stepkut> with out disturbing XMLT (the theorectical XML generation monad) or RouteT
15:53:32 <stepkut> i'll have to investigate this alternative snaplet approach I guess
15:55:50 <stepkut> and, of course, the main problem with wrapping things around FoundationT is that you have to recreate the class instances like MonadRoute, etc
15:56:08 <stepkut> you can use GeneralizedNewtypeDeriving for most things..but not for HSX
15:56:14 <donri> well by snaplets i mean for happstack 8 and replacing all/most of our mtl-style monad transformers
15:56:38 <stepkut> I am not against the idea, just not clear how it would work :)
15:56:52 <donri> but, i don't know if there's downsides to that, which is what i was originally asking about :)
15:57:56 <donri> i think for now the real solution is to make happstack-clientsession-hsx and use that in foundation instead of web-routes-hsx
15:58:17 <stepkut> I don't think so..
15:58:47 <stepkut> it seems silly keep creating XMLGen, EmbedAsChild, and EmbedAsAttr instances everytime we add a new monad transformer
15:58:48 <donri> well, if you're fixing hsx, then perhaps not
15:58:58 <donri> yes, i very much agree on that point :)
15:59:39 <stepkut> one part is to create a monad transformer that is isomorphic to IdentityT but is for generating XML
16:00:04 <stepkut> the other part is to create a deriveXMLGen TH function that will attempt to do what GeneralizedNewtypeDeriving can not
16:00:15 <donri> how is XMLT different from XMLGenT anyway
16:00:48 <stepkut> hmm
16:01:03 <KBme> hello
16:01:05 <stepkut> well, the definition is the same
16:01:15 <donri> ohai
16:01:17 <stepkut> not sure what would happen if we try to create XMLGenerator instances directly for XMLGenT
16:01:20 <donri> nice ip
16:01:49 <stepkut> heh
16:02:30 <KBme> gotta luv da v6
16:03:10 <stepkut> stacking monad transformers is annoying.. I feel like there was some other mechanism for composing them like, StateT st :+: ReaderT r :+: WriterT w, but you have to redo all your mondas from the ground up to support that.. and there was maybe some issues
16:04:16 <donri> we could simply ditch mtl and go tekmo style pure-transformers ;)
16:04:35 <donri> rq <- lift . lift . lift . lift $ ask
16:04:57 <donri> lift . lift . lift $ put "i'm in the session!"
16:05:13 <donri> lift . lift $ <body>ohai response</body>
16:05:16 <donri> AWESOME
16:54:03 <LambdaDusk> donri: Still have time and feel like helping a noob?
16:54:11 <donri> sure
16:56:33 <LambdaDusk> yay
16:58:30 <LambdaDusk> donri: For a reason I can't fathom, this line is called on window load: https://github.com/scan/neighr/blob/master/src/Template.hs#L78
17:00:31 <LambdaDusk> donri: Looks like this is the generated stuff from jMacro: https://gist.github.com/842c678aa9ff76428069
17:01:03 <LambdaDusk> I think I know why
17:01:04 <LambdaDusk> hah
17:01:57 <LambdaDusk> in this line here: https://github.com/scan/neighr/blob/master/src/Template.hs#L77
17:01:59 <LambdaDusk> it produces "null" as string, and not null as value
17:03:16 <donri> yea, jmacro splicing is type safe
17:04:03 <donri> maybe for currentUser do something like this instead
17:04:12 <donri> Nothing -> [jmacroE|null|]
17:04:40 <donri> Nothing -> return [jmacroE|null|] -- i meant
17:05:01 <donri> Just e -> return $ toJExpr $ T.unpack e
17:06:43 <donri> so currentUser is a JExpr instead of a String
17:06:50 <LambdaDusk> hm ok
17:07:07 <donri> that way it can be both a JS string or JS null
17:07:09 <LambdaDusk> it is still called for no reason =/
17:07:53 <donri> i suspect it has nothing to do with jmacro (or haskell etc) but the js itself or something?
17:08:15 <LambdaDusk> it is strange because it is almost verbatim from here https://developer.mozilla.org/en-US/docs/Persona/Quick_Setup?redirectlocale=en-US&redirectslug=BrowserID%2FQuick_Setup
17:13:48 <LambdaDusk> It seems that this is really some other problem
17:23:26 <donri> sorry i'm not of more help
17:23:31 <donri> don't really know js or browserid all that well
17:26:58 <LambdaDusk> donri: No problem there
17:27:53 <LambdaDusk> donri: But you can have a look at this function: https://github.com/scan/neighr/blob/master/src/Auth.hs#L30 and tell me how to improve it, perhaps...?
17:30:43 <LambdaDusk> have your heard that the next ghc version will have an option to switch off type checking?
17:32:30 <donri> well, defer
17:32:43 <LambdaDusk> lazy type checking
17:32:50 <donri> :)
17:33:03 <donri> i suggest lenses for your request state stuff
17:33:13 <donri> and maybe something more interesting than a tuple
17:33:36 <LambdaDusk> there are more interesting things than a tuple?
17:33:51 <donri> a data type?
17:34:01 <LambdaDusk> hm
17:34:04 <LambdaDusk> well yeah
17:36:07 <donri> data RequestState = RequestState { _integerSupply :: Integer, _sessionData :: SessionData }; makeLenses ''RequestState
17:37:37 <LambdaDusk> hmm...
17:40:36 <LambdaDusk> I've kind of stepped away from lenses because I did not see how they differ from just using the function from the record
17:43:55 <donri> nextInteger = modifyRequestState $ integerSupply +~ 1
17:44:26 <donri> hm actually no
17:45:36 <LambdaDusk> no?
17:46:26 <donri> no that doesn't return the new integer
17:47:12 <donri> if only foundation provided lenses and lens provided stateful increment with pass-through :(
17:47:59 <LambdaDusk> looks like foundation deserved some work
17:48:13 <donri> then we could have, nextInteger = reqSt.integerSupply <+= 1
17:48:32 <LambdaDusk> cufp sounds interesting, but I can't believe there's actually "commercial uses" for haskell yet
17:50:26 <donri> ah there is <+=
17:51:23 <LambdaDusk> where?
17:51:29 <donri> @hackage lens
17:51:29 <lambdabot> http://hackage.haskell.org/package/lens
17:53:04 <donri> requestState = lens reqST $ \appState -> appState { reqSt = st }
17:53:18 <donri> nextInteger = requestState.integerSupply <+= 1
17:55:03 <donri> requireUser = do muid <- gets (^.sessionData.to fromSession); maybe mzero ... muid
17:56:11 <LambdaDusk> hmm
17:57:25 <donri> uuh
17:57:33 <donri> requireUser = do muid <- gets (^.requestState.sessionData.to fromSession); maybe mzero ... muid
17:58:29 <LambdaDusk> what do others use for login stuffs?
17:59:26 <donri> currentUser <- maybe [jmacroE|null|] T.unpack <$> gets (^.requestState.sessionData.to fromSession)
17:59:57 <donri> oh duno, happstack-authenticate maybe, or browserid like you
18:00:39 <LambdaDusk> so what you just wrote, is that applicable right now to my code or not because of foundation being not complete?
18:00:57 <donri> applicable now
18:01:03 <donri> if you define requestState like i did
18:01:18 <LambdaDusk> but reqSt is not exposed from foundation
18:01:21 <donri> no wait
18:01:21 <donri> yea
18:01:26 <donri> stepcut: !
18:01:29 <donri> silly boy!
18:02:19 <LambdaDusk> I told him before that the requestState is not reachable, then he added getRequestState et al functions
18:02:31 <donri> also i defined it wrong
18:02:56 <LambdaDusk> joy
18:05:03 <donri> requestState = lens reqST $ \appState st -> appState { reqSt = st } -- i think
18:05:23 <donri> that's what you get for live-coding in the irc client without running a type checker ;)
18:07:10 <LambdaDusk> @lambdabot type check for me
18:07:11 <lambdabot> Unknown command, try @list
18:07:21 <LambdaDusk> stupid bot
18:07:49 <LambdaDusk> oh god last night I had this dream that my entire life is type checked =/
18:08:21 <LambdaDusk> it made huge sense the night, it doesn't now
18:09:37 <donri> i've had such dreams too
18:11:04 <LambdaDusk> ah well
18:11:23 <LambdaDusk> reqSt is not exposed, but I will turn the tuple to a full data type
18:19:05 <LambdaDusk> I think I just lost some... motivation...
18:19:30 <donri> \o/
18:20:09 <LambdaDusk> what's that mean?
18:20:38 <donri> "yay!" D:
18:20:39 <donri> :D
18:21:22 <LambdaDusk> i am still not too motivated to continue because it feels like swimming through syrup
18:21:29 <LambdaDusk> like a car stuck in the mud
18:38:24 <donri> know the feeling
20:08:37 <LambdaDusk> hah
20:08:52 <LambdaDusk> when type safe obscures an error with types
20:08:53 <LambdaDusk> wow
20:10:19 <LambdaDusk> and it solves and problem I had
20:11:06 <donri> :D
20:12:04 <LambdaDusk> I had not seen the bug because the typechecker accepted it
20:12:20 <donri> what was the bug
20:13:05 <LambdaDusk> https://github.com/scan/neighr/blob/master/src/Main.hs#L41
20:13:06 <LambdaDusk> this seralized the requestState into the cookie
20:13:13 <LambdaDusk> instead of just the session data
20:13:36 <LambdaDusk> it worked when I was using only SessionData as the requestState
20:13:42 <LambdaDusk> then I added the integer supply
20:13:45 <LambdaDusk> as a tuple
20:13:56 <LambdaDusk> the tuple was still an instance of SafeCopy
20:14:02 <LambdaDusk> so the typechecker did not complain
20:14:07 <LambdaDusk> it should have
20:14:14 <LambdaDusk> but yeah
20:14:26 <LambdaDusk> so I thought this part was fine - tested and checked
20:16:53 <donri> ah
20:17:44 <donri> in happstack-clientsession you'd have the session type in the type signature
20:18:09 <donri> and well it would handle the serializing for you anyway so yea
20:18:10 <donri> ^_^
20:27:59 <LambdaDusk> YES IT WORKS; FINALLY!
20:28:27 <LambdaDusk> yes but I can't used happstack-clientsession together with happstack-foundation
20:38:17 <donri> yea
20:38:26 <donri> did you figure out the browserid bug?
20:41:00 <LambdaDusk> it was some state browser problem... seems like browserid is stateful
20:41:29 <LambdaDusk> once I corrected the session problem, it disappeared by itself because "loggedInEmail" was now set correctly
20:43:29 <LambdaDusk> all right now... loggin in, routing, all done
20:43:32 <LambdaDusk> wow
20:43:37 <LambdaDusk> no idea what to do next
20:58:39 <hpaste> LambdaDusk pasted “Helpers.hs” at http://hpaste.org/74647
20:59:01 <LambdaDusk> donri: Perhaps help me there if you got a minute?
21:00:30 <stepkut> what is the type of 'classes' ?
21:01:53 <LambdaDusk> uh
21:01:57 <LambdaDusk> just a string...?
21:02:20 <LambdaDusk> classes :: Bool -> String
21:02:27 <LambdaDusk> in the where clause
21:02:52 <LambdaDusk> wow when I fix the type it works, am I dumb
21:03:02 <stepkut> :)
21:03:40 <donri> LambdaDusk: i think the issue is you have overloadedstrings, but you're not giving classes a type sig
21:03:48 <donri> so it's IsString a => Bool -> a
21:03:58 <donri> and then hsx doesn't know which embed instance to use for that
21:04:07 <donri> for string literals in xml, hsx adds ::String
21:04:12 <LambdaDusk> perhaps add an embed instance for IsString a ?
21:04:32 <stepkut> donri: well, that would be reflect in the type of classes..
21:05:23 <stepkut> uh
21:05:45 <donri> not sure about that
21:05:45 <stepkut> well, I think you should just ignore that
21:05:53 <donri> overlapping instances and overloaded strings, things go wrong ;)
21:05:57 <stepkut> yes
21:06:14 <stepkut> if the code actually contained the type signature, classes :: Bool -> String, then OverloadedStrinsg wouldn't make a difference
21:06:25 <donri> yea, that's what i suspect
21:06:36 <stepkut> if the type was infered, then it would, because the compile would infer, classes :: (IsString a) => Bool -> a, which is what you were suggesting
21:07:25 <LambdaDusk> yes I added the signature
21:07:33 <LambdaDusk> I feel bad for bothering you with that
21:08:21 <stepkut> 'tis ok
21:08:52 <donri> not sure we can have an IsString embed instance btw
21:09:08 <stepkut> the key lines of that type error are 60 and 61
21:09:36 <stepkut> the fact that that simple mistake results in a 50 line type error is why I am hesistent to recommend HSP sometimes
21:09:38 <donri> instance (IsString a, EmbedAsAttr m (Attr String a)) => EmbedAsAttr m (Attr String a) where asAttr = asAttr . fromString
21:09:40 <donri> it doesn't work
21:09:54 <stepkut> but, something that the new haskell source types library should help with
21:10:07 <stepkut> donri: right, ambiguous types
21:10:16 <donri> well, recursive type
21:10:18 <donri> and wrong type
21:10:42 <stepkut> LambdaDusk: when you get those giant type errors, there is usually a spot in the middle that tells you something sensible, surrounded by a bunch of noise
21:11:13 <stepkut> so, the key is to first find the part of the error that tells you what expression it actually had a problem with
21:11:37 <stepkut> then we look at the error above it and see that it is having a hard time figuring out the specific type of the Attr value
21:12:07 <donri> i think what we need is the inverse of fromString, like, toString
21:12:21 <LambdaDusk> I guess when I work more with HSP then I will learn eventually to dealwith it
21:12:38 <LambdaDusk> donri: You mean, Show?
21:13:04 <stepkut> :)
21:13:18 <donri> no i mean where toString = id for String
21:13:54 <donri> @check \s -> show s == (s :: String)
21:13:55 <lambdabot>   "Falsifiable, after 0 tests:\n\"\\869148\"\n"
21:14:36 <LambdaDusk> @check \s -> s == id s
21:14:37 <lambdabot>   "OK, passed 500 tests."
21:14:40 <LambdaDusk> yay
21:15:21 <donri> @check id
21:15:22 <lambdabot>   "Arguments exhausted after 0 tests."
21:15:28 <donri> @check not
21:15:29 <lambdabot>   "Falsifiable, after 1 tests:\nTrue\n"
21:15:35 <donri> @check (not.not)
21:15:37 <lambdabot>   "Falsifiable, after 4 tests:\nFalse\n"
21:16:19 <donri> actually not sure ToString would be enough either
21:16:39 <donri> we need an arrowized embed :P
21:16:51 <LambdaDusk> there must be a monad, too!
21:17:03 <LambdaDusk> and a comonad
21:17:11 <LambdaDusk> and whatever keyword I can find
21:17:47 <donri> or hm
21:18:34 <donri> instance (IsString a, ToString a, EmbedAsAttr m (Attr String String)) => EmbedAsAttr m (Attr String a) where asAttr (k := v) = asAttr (j := toString v)
21:19:00 <donri> s/j/k
21:19:34 <LambdaDusk> I love type signatures three times longer than the function itself
21:19:39 <donri> :)
21:29:26 <LambdaDusk> could i use "when" in an HSP?
21:29:53 <donri> sure thing
21:30:26 <LambdaDusk> nope
21:30:48 <donri> or the listcomp trick [ doThis | ifThis == that ]
21:31:19 <LambdaDusk> http://hpaste.org/74647#line24 can't turn that into a when
21:32:44 <donri> <% [ <button type="button" class="close" data-dismiss="modal" aria-hidden="true">&times;</button> | closable ] %>
21:34:14 <LambdaDusk> hah
21:34:25 <donri> <% when closable <button type="button" class="close" data-dismiss="modal" aria-hidden="true">&times;</button> %> -- i imagine this should work?
21:34:36 <stepkut> donri: neat. I never thought of doing it that way. going to have to update the crash course. :)
21:34:51 <donri> got it from chrisdone :)
21:34:57 <LambdaDusk> this is crazy
21:35:10 <LambdaDusk> you guys are crazy
21:35:20 <donri> ^_^
21:35:22 <stepkut> :)
21:36:21 <donri> > ([ "yep" | True ],[ "nope" | False ])
21:36:22 <lambdabot>   (["yep"],[])
21:37:26 <LambdaDusk> let m = forkIO m in m
21:37:56 <donri> @src fix
21:37:56 <lambdabot> fix f = let x = f x in x
21:38:08 <donri> fix forkIO
21:38:47 <LambdaDusk> is the bot protected?
21:38:53 <donri> sure thang
21:39:12 <donri> timeouts on eval and no IO
21:39:52 <LambdaDusk> ah
21:39:57 <LambdaDusk> anyway, thanks
21:40:04 <LambdaDusk> I will head to bed now
21:40:23 <donri> sleep tight
21:40:55 <LambdaDusk> stepkut: Look at my github repo for that foundation-compatible session
21:49:55 <donri> compatible by not introducing a transformer because it decrypts on each request regardless of use and relies on Eq to avoid encrypt after each request if not written
21:50:21 <donri> which might be fine for his app, but perhaps not for foundation itself