04:12:24 <mightybyte> Dude's got skillz.
12:26:34 <alpounet> stepcut, soooo, the dependency tracking service needs to compare wrt the local hackage db right?
14:01:40 <stepcut> alpounet: hmm
14:02:22 <stepcut> not sure
14:03:41 <alpounet> the "source db" then?
14:04:48 <stepcut> not sure
14:05:55 <stepcut> we have a bunch of services like the haddock builder and the builder bot that need to run when source has changed since the last time they ran
14:06:29 <stepcut> but.. I am not quite sure how the details play out there
14:06:52 <stepcut> like.. what happens if the server goes down.. how do we know what work still needs to be done?
14:07:31 <stepcut> maybe everytime we see a source change, we create some new record of what we have and give it an (incrementing) ID number
14:07:45 <stepcut> then each service can check if they have handled that ID already or not?
14:08:34 <stepcut> my theory (at this point) is that nothing in the LocalHackage service should be precious.. you should be able to wipe it out and do a new run and it will be properly repopulated
15:30:28 <alpounet> stepcut, yes but we also need to store informations about packages, like the ones you mentionned
15:30:34 <alpounet> information*
15:30:44 <stepcut> yes
15:30:58 <stepcut> not sure that LocalHackage is the place to store that though
15:31:03 <alpounet> ok
15:31:08 <alpounet> the source cache neither, then
15:31:14 <stepcut> right
15:31:49 <alpounet> so, a kind of "scoutess" dir, relative to the project being handled by scoutess
15:32:23 <stepcut> hmm
15:32:31 <stepcut> I figured the information would be stored in a database..
15:33:08 <stepcut> in other news, the irc logging has been migrated to the new website:  http://www.happstack.com/I/IrcLogs
15:35:37 <alpounet> nice
15:35:53 <alpounet> stepcut, acid-state? hah
15:36:17 <stepcut> ?
15:37:18 <stepcut> hmm. seems like log files that contain unicode do not render correctly
15:37:21 <stepcut> I'll have to fix that.
15:37:30 <stepcut> but at least the logs are being created
15:37:51 <stepcut> and the old server is fully removed now
15:38:18 <siracusa> stepcut: According to the freenode guidelines, public logging should be annouced in the topic
15:40:17 <stepcut> done
15:40:51 <siracusa> Nice :-)
15:41:06 <stepcut> just gotta fix the utf-8 issue now
15:41:56 <stepcut> or maybe the problem is when files contain broken utf-8 or something
16:07:48 <stepcut> alpounet: sorry, a bit distracted. Trying to find my stapler so I can finish my taxes.
16:08:22 <stepcut> I think the last time I used it was last april.. and I have moved since then
16:09:44 <alpounet> hah
16:09:48 <alpounet> good luck for finding it
16:13:52 <stepcut> found it!
18:10:37 <luite> yay new plugins!
18:10:50 <luite> stepkut: this one works with all recent compilers?
18:13:57 <stepkut> I hope so
18:14:00 <stepkut> that is the idea anyway
18:14:05 <stepkut> should work with GHC 6.12 still too
18:14:12 <stepkut> I am writing the release notes now
18:14:21 <luite> cool
19:07:00 <stepkut> oh nice.. if you write a thoughtful reply on ycombinator, then by the time you are done, the post link has expired
19:07:11 <mightybyte> I hate that.
19:07:34 <mightybyte> Continuation web servers FTL
19:13:47 <donri> really tiobe, D and groovy are bigger than haskell?
19:15:18 <stepkut> donri: regarding darcs-bridge, the warning says, "if you're hoping to maintain a long-term bridge and you have to deal with Git branches, we'd advise waiting. "
19:15:35 <stepkut> donri: so, maybe I can still only have a single public git branch and be ok ?
19:18:21 <donri> maybe yea
19:19:01 <donri> if it mirrors a darcs repo there's no point in branches in the mirror itself
19:19:14 <donri> only in forks where you're going to merge certain branches into your single branch anwyay
19:21:14 <stepkut> yeah
19:21:23 <stepkut> that is all I want to do
19:21:30 <stepkut> pull requests on github into the mainline
20:09:18 <donri> yesod announces 1.0 on reddit, most comments have negative points. *why* do i continue to read reddit. -.-
20:09:34 <stepkut> heh
20:10:03 <luite> part of the reason is that it's announce in /r/programming
20:10:07 <luite> or at least announced first there
20:10:14 <donri> oh just noticed
20:10:39 <donri> i was wondering why those people were reading /r/haskell
20:10:58 <donri> ... *why* do i continue to read /r/programming. ^_^
20:11:51 <donri> ok in the /r/haskell post 50% of the comments have 0 points ;)
20:12:03 <donri> ACTION *snrk*
20:14:41 <luite> Michael is taking a cue from Rails with his marketing material, I can imagine tat some people don't really like that :)
20:15:29 <donri> well yesod *is* the rails of haskell
20:15:41 <mightybyte> I stopped reading proggit years ago.
20:15:47 <mightybyte> Awful SNR
20:19:17 <luite> donri: hehe some people don't like that "accusation" :p
20:19:32 <luite> depends on your perspective whether you view it as such
20:20:14 <donri> i think those people may put too much weight on the "rails" in that. i'm saying it's the rails of *haskell*, put the weight on the latter ;)
20:20:50 <donri> also "rails without the ruby" ;)
21:22:42 <parcs`> what is snr?
21:24:03 <parcs`> oh, signal to noise
21:24:57 <stepkut> donri: sessions!
21:31:33 <stepkut> motto of the day: If you hate Haskell then you're really going to hate Happstack!
21:32:27 <luite> hmm, is there also an iff implied? ;p
22:53:36 <stepkut> donri: did you see this discussion about encrypted cookies, http://news.ycombinator.com/item?id=3816958
23:27:31 <donri> yea they seem to miss the point that it's to prevent to *user* to read the cookie
23:27:33 <donri> "just in case"
23:27:49 <donri> if it doesn't add a big overhead i'd call it a good thing?
23:28:10 <luite> it's really fast
23:28:56 <luite> a modern cpu can encrypt a few GB per second (with AES-NI and OpenSSL), so I don't really understand the problem
23:29:28 <donri> yea as i said they seem to miss the point about hiding it from the user too (not just eavesdroppers)
23:29:29 <luite> I didn't feel like arguing on that thread though, too much hostility :(
23:29:44 <stepcut> if you don't want the user to read it.. maybe it should go in a cookie in the first place? I dunno..
23:29:53 <donri> i too can't really think of a situation where that is important, but i'd like to not *have* to think about it :)
23:30:24 <luite> stepkut: nah I don't agree. if you have some small state, even if it's secret, why shouldn't it be able to go in the session/cookie?
23:30:34 <donri> stepkut: by that argument the signing is "wrong" too
23:30:48 <stepcut> donri: oh ?
23:31:15 <donri> "if you don't want the user to manipulate it, don't put it in a cookie"
23:33:52 <stepcut> ok
23:34:06 <donri> shrug :)
23:34:10 <stepcut> :)
23:34:20 <stepcut> anyway, I just wondered if you had read the thread
23:34:33 <stepcut> not saying he is right or wrong
23:34:41 <donri> more interesting i think is that a cookie imposes size limits and overhead even for asset requests
23:34:57 <stepcut> but, that if we want to encrypt our cookies, we should be clear in the docs about what exactly you are getting and what you aren'nt
23:34:57 <donri> while on the other hand a sessio id has problems too. why can't we have magical solutions :(
23:35:38 <donri> yea i don't think yesod encrypts other cookies, only the session
23:35:53 <donri> because the cookie is used to "fake" server-side data storage
23:36:21 <stepcut> where does Key come from ?
23:36:41 <donri> it can be generated and stored in a file
23:36:54 <stepcut> so, there is one private key that encrypts all cookies?
23:37:18 <donri> duno about encryption, i think the Key is for signing?
23:37:22 <donri> luite!
23:37:36 <luite> sorry was a bit distracted
23:37:45 <donri> :D
23:38:31 <luite> yesod uses a single key to encrypt and decrypt cookies yes, it's symmetric enctyption, no RSA
23:38:47 <luite> and it uses hash authentication
23:38:48 <stepcut> seems like putting data you don't want the user to know into a cookie and giving it to them is dangerous because if the encryption key ever gets leaked, all users can then decrypt their private data?
23:39:13 <luite> and random initialization vectors from a cryptographically secure rng
23:39:30 <donri> true, while if they could just sign a fake session you could just generate a new key if you knew it leaked
23:39:34 <luite> yes if the key leaks out, they can decrypt the data
23:40:19 <luite> the idea is that this gives you an efficient way to do sessions without server-side state
23:40:31 <luite> but it has some limitations, I don't think the key leaking issue is the worst one
23:41:41 <luite> I think the main one is that is susceptible to replay attacks, you can  never securely log out of a site with this, since someone could steal an older cookie and use that to work under your account
23:41:51 <stepcut> yeah
23:42:35 <donri> well, you also encode the IP by default which mostly prevents that but adds new problems
23:42:44 <stepcut> yup
23:43:20 <donri> IP is rather useless though to rely on for security
23:43:43 <donri> some of the situations where an eavesdropped could steal the cookie also imply they have the same IP (e.g. public WLAN)
23:44:01 <stepcut> yes.. this is why happstack doesn't have a session library yet.. implement sessions is easy. Implementing them correctly.. no so much :)
23:44:21 <donri> so instead we have users implementing them not even close to correctly for each app? :D
23:44:44 <stepcut> exactly!
23:44:47 <donri> yay!
23:44:57 <luite> donri: getting the correct IP also requires knowledge by the web framework about how to get the remote IP
23:44:57 <stepcut> we should fix that
23:45:47 <donri> screw sessions, let's just use ssl and http basic auth
23:46:41 <donri> (doesn't ssl break when keys are leaked too?)
23:47:02 <luite> yes
23:47:15 <luite> same problem with private key on the server
23:47:20 <stepcut> http basic/digest auth would be pretty sweet if it didn't have to open some external popup window :(
23:50:30 <luite> hm, I think basic auth is pretty annoying
23:50:38 <luite> you don't have control over the logins
23:50:42 <donri> i wonder if browserid could work similarly in the future, send with each request, validated, so we don't need sessions
23:51:08 <luite> for example if you have logged in at work and at home, both browsers still open
23:51:21 <luite> then you can't log out the work session from home
23:51:25 <donri> why do people use sessions for flash messages btw? why not just a normal session cookie
23:51:45 <luite> and the other way around, you can't make sessions that survive a browser restart
23:51:54 <luite> logins I mean
23:55:13 <luite> donri: why don't you need sessions then? if someone has two computers logged into the same account, they could be used for different things
23:56:09 <donri> example?
23:58:38 <donri> stepcut: should be possible to do login via a html form if you allow javascript in the mix? just redirect to https://user:passwd@site...
23:59:00 <donri> hm perhaps could even do the redirect server-side ...
23:59:47 <donri> i think browsers hide the user:passwd from the URL so you cant' accidentally link it?