13:23:32 <LambdaDusk> is it known that HJScript fails to compile?
13:24:32 <stepcut> compiles for me..
13:25:30 <stepcut> oh
13:25:34 <stepcut> maybe I am applying patches
13:25:35 <stepcut> one moment
13:29:29 <hpaste> stepcut pasted HJScript patch at http://hpaste.org/66645
13:33:22 <hpaste> stepcut pasted patch for HSP + GHC 7.x at http://hpaste.org/66647
13:34:17 <stepcut> I email Niklas.
13:56:42 <LambdaDusk> Though I am also unsure which template engine because I am so used to Jade
14:13:10 <stepcut> what is Jade like?
16:30:46 <stepcut> fo
16:31:06 <stepcut> bar
16:31:15 <stepcut> hmm
16:32:43 <DMcGill> stepcut: coming through loud and clear
16:33:24 <stepcut> I have a button to restart  the bot
16:33:42 <stepcut> but it only works if the bot receives two lines of text from the server after you press it
16:34:28 <stepcut> going to try something different, one moment
16:37:29 <stepcut> better!
16:37:41 <stepcut> not perfect, but good enough.
16:40:13 <stepcut> making a good ircbot library is hard work :)
16:40:22 <stepcut> going to have to settle for 'good enough' for now
16:44:01 <stepcut> donri: how's sessions looking?
17:19:53 <donri> stepcut: duno just woke up a minute ago ;)
17:21:28 <stepcut> :)
17:28:46 <luite> donri: it's Text,ByteString I think, in Yesod, with some utility to convert
17:29:01 <luite> sessions
17:29:49 <stepcut> donri: I am definitely in favor of making the session type itself be 'a', while also providing a, Map Text ByteString, version or something
17:29:51 <luite> it could be relaxed a bit, but I think it would either need to be serializable, or there would need to be some type families
17:31:15 <stepcut> donri: you can have a, Session a, type that you store in acid-state. But you can't actually call makeAcidic for the user.. because they user needs a way to add the extra events they needed for manipulating their state
17:32:38 <luite> hmm, I personally think that acid-state might not be ideal for sessions, unless you have some way to make a distributed acid-state store
17:32:45 <donri> luite: i already combined clientsession and safecopy sucessfully
17:33:05 <donri> but we're also looking to implement server-side sessions via session IDs
17:33:54 <luite> yeah, that was added recently in yesod
17:34:00 <donri> ah, cool
17:34:18 <donri> wait, which part?
17:34:20 <luite> but still with the Text -> ByteString map as the basis
17:34:53 <luite> oh the session backend is configurable now
17:35:07 <luite> and there are backends for ClientSession and for Redis
17:35:15 <donri> the problem with clientsession is size limits and the need to put assets on a separate server
17:35:17 <luite> though I think the latter still needs an updated
17:35:51 <donri> ...the problem with serversession is the need to do db writes to update the expiration, but i think stepcut's idea is sound in that regard
17:36:03 <luite> we went with a simpler design than Snap btw, they have a more elaborate session backend that can retrieve and update individual keys
17:36:30 <luite> yesod restores the session at the start of each request, saves it at the end
17:36:42 <LambdaDusk> luite: I did not quite add my redis backend for the recent code change
17:37:00 <luite> LambdaDusk: right, I can send you a pull request if oyu have trouble updating
17:37:18 <donri> yea my clientsession code is currently rather bad, doing decrypt and encrypt for every get/put during a request
17:37:20 <LambdaDusk> luite: I always have with changes not in the yackage =/
17:37:21 <luite> donri: there was an api change to make it possible for backends not to update expiration every request
17:37:40 <LambdaDusk> I just wanted to prevent you advertising a feature that is not done yet
17:37:57 <luite> donri: what was stepcuts idea for this?
17:38:13 <donri> stepcut: hey btw what happens if you change a cookie and then get the cookie? do you get the updated cookie or the original cookie? during the same request
17:39:06 <LambdaDusk> looks like Heist is the best engine for what I want =/
17:39:09 <donri> luite: the idea is that queries are cheap in acid-state, much cheaper than updates, so you could do a query for every request to see if the expiration needs to be updated or not, with a minute or so uh "grace period" what's a good word
17:39:27 <donri> luite: so that a bunch of simultanous requests for js/css/images doesn't trigger writes
17:39:32 <luite> donri: right, that's exactly the use case that I updated the yesod session api for
17:39:49 <luite> and the reason that the Redis backand doesn't quite work yet :)
17:40:20 <LambdaDusk> I gather I'd have to change the return for the get part
17:40:35 <LambdaDusk> you must know I am a noob =/
17:40:44 <luite> yeah you return the setter in the getter
17:41:04 <luite> but this way, you can remember some data in the closure you return
17:41:11 <LambdaDusk> I see
17:41:11 <luite> like the old session, and its expiration time
17:41:29 <donri> (not that writes are expensive in acid-state. i think stepcut peaked it at 20k writes per second? in a benchmark)
17:41:56 <donri> (but queries are "practically free")
17:41:59 <luite> donri: yeah well, the problem for yesod is that we wanted distributed sessions, and there writes are potentially really expensive
17:42:12 <donri> yea
17:42:18 <LambdaDusk> luite: I am sure I can write another using persistent or something
17:42:32 <luite> LambdaDusk: yeah acid-state would also be nice for single-server solutions
17:42:39 <donri> replication and sharding is on the roadmap for acid-state, and obviously would make both queries and updates more expensive
17:43:08 <LambdaDusk> luite: I must say I don't trust acid-state because leaks can happen easily
17:43:24 <donri> (would be interesting to run that same benchmark over the remote backend that already exists)
17:43:34 <luite> though the current api is optimized for small data, since it requires the whole session to be restored to the Text->ByteString map every request
17:43:52 <luite> I think the reasoning is that if you have large data, store some identifier in the session
17:43:54 <LambdaDusk> Sessions should be small anyway
17:44:04 <luite> and use an API with more control for the real data
17:44:07 <LambdaDusk> use the DB for large data
17:44:26 <luite> yeah well, there are probably use cases where storign lots in the session is easier
17:44:28 <donri> i just feel that if we can figure out a way to not have to *think* about keeping the session small, that's a plus
17:45:10 <LambdaDusk> I am trying to think of any
17:45:52 <luite> donri: yeah I agree, but that would require some compromises, acid-state is probably the only server-side backend where it would be viable
17:46:09 <donri> in most cases, you just store a lookup key for e.g. logged in user in the session, or use some html5 api for client-side storage of larger data that's client-local
17:46:09 <luite> and then you lose distributed sessions, at least with the current version
17:46:40 <luite> I think Snap allows session backends to restore individual session keys
17:46:49 <luite> instead of the whole session at once
17:46:50 <donri> luite: yes, that's kinda the point :) we have the potential to experiment with that sort of thing simply because of acid-state
17:47:04 <luite> but I feel that it's too complex for this
17:48:14 <LambdaDusk> my session currently only saves the user id and I think thats fine
17:48:31 <luite> donri: right, I'd like to see an acid-state backend for yesod sessions as well
17:48:51 <stepcut> donri: you get the original cookie. addCookie never takes effect until you send the Response and get a new Request
17:49:08 <LambdaDusk> luite: how would you do the expiration there?
17:50:12 <luite> LambdaDusk: forkIO a thread that does cleanup, or scan for expired keys when a new one is added (probably with a maximum of once every 5 minutes or so)
17:50:36 <luite> LambdaDusk: you can forkIO the thread when you return the session backend for example
17:50:39 <LambdaDusk> .... damn I never get the simple solutions
17:50:44 <luite> since that's an IO action
17:54:47 <LambdaDusk> ok anyone have a project that uses distributed heist (with defaultTemplate). Once again, I fail to see how to start
17:54:56 <luite> LambdaDusk: can you also update it so that it doesn't use a write query when the session hasn't changed, and with the expiration time grace period (I'm pretty sure that stepcut stole that idea from me btw ;p )
17:55:53 <stepcut> luite: no.. I have had the idea since before yesod existed.. just have not gotten around to writing a real session library yet :(
17:56:14 <stepcut> LambdaDusk: distributed?
17:56:16 <luite> lalalala can't hear you ;p
17:57:31 <stepcut> I also implemented type-safe urls before yesod existed :p
17:58:55 <stepcut> happstack-telnet doesn't get enough love :-/
18:04:24 <donri> simpleGopher?
18:04:55 <LambdaDusk> happstack-telnet? You can write a MUD with that!
18:06:52 <stepcut> LambdaDusk: http://groups.google.com/group/happs/browse_thread/thread/d43f4a6087820006?fwc=1
18:07:17 <stepcut> server is no longer running
18:07:51 <LambdaDusk> awww
18:08:56 <stepcut> you can get the source and run it yourself though
18:09:19 <stepcut> there was a little, realtime multiplayer maze game
19:11:30 <stepcut> released ircbot 0.4 and 0.5 today :p
19:12:48 <mightybyte> nice
19:14:02 <stepcut> I still have at least of week of work I could do on ircbot though.. alas, there are more important things todo
19:14:32 <mightybyte> I'm still annoyed that my irc bot dies every time there's a netsplit.
19:15:17 <alpounet> stepcut, what's new?
19:16:00 <stepcut> alpounet: simpleBot now also returns an, IO (), action which you can call (repeatedly) to force the bot to reconnect
19:16:13 <stepcut> alpounet: and it now has an optional rate limiter for PRIVMSG and NOTICE messages
19:16:37 <alpounet> oh, nice :)
19:16:45 <stepcut> alpounet: the force reconnect code is a tiny bit flakey though.. hClose can block if hGetLine is blocked
19:17:36 <alpounet> that's still nice to have a first version
19:17:56 <stepcut> yeah
19:18:36 <stepcut> not quite sure what the right fix is.. probably need to kill some threads and restart them
19:24:28 <alpounet> yeah i guess
23:11:16 <donri> stepcut: "Darcs bridge isn't ready for prime time, we're afraid.  It's good for one-shot conversions, but if you're hoping to maintain a long-term bridge and you have to deal with Git branches, we'd advise waiting."
23:11:20 <donri> http://blog.darcs.net/2012/04/darcs-hacking-sprint-7-report.html
23:38:51 <stepcut> :(
23:39:14 <stepcut> screw you Linus!