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!