00:00:11 <donri> snapstack
00:00:58 <tazjin> I actually laughed out loud, though that might've something to do with this Bavarian brew I've been consuming
00:03:16 <donri> Comed-Tea?
00:04:33 <tazjin> No, that's non-canon
00:05:12 <tazjin> Actually more like this: http://4.bp.blogspot.com/-f36d2eRF8XE/T9IlwxCxJWI/AAAAAAAACLU/vRBmGymWD0Q/s1600/Altenm%25C3%25BCnster%2Burig%2Bw%25C3%25BCrzig%2B2.jpg
10:46:55 <alpounet> uh, xkcd uses happstack http://www.reddit.com/r/haskell/comments/uved7/waldo_the_haskell_powered_codebase_behind_xkcds/
10:53:06 <HugoDaniel> :)
10:53:09 <HugoDaniel> amazing
14:35:52 <stepcut> yup
14:36:07 <stepcut> they even submit darcs patches!
15:16:56 <kstt> hello
15:17:21 <kstt> what is the behaviour of lookFile when the form user does not supply a file in the input field please ?
15:19:43 <stepcut> kstt: depends on what the browser does, but it seems to me that most browsers submit a 0-length file with an empty name
15:20:19 <stepcut> so, lookFile will probably return successfully, but the name supplied by the browser will be "" and the temp file will be empty
15:20:34 <stepcut> would be better if it failed probably
15:20:47 <kstt> Ah thanks. This explains the behaviour I'm seeing. I expected the monadPlus to mzero on missing field, but it just passes through until later crash.
15:21:17 <stepcut> yeah.. the field is not actually missing, it's there but contains no data :-/
15:21:52 <stepcut> I am not clear why they do that
15:21:58 <stepcut> (they == the browser people)
15:22:23 <stepcut> the behavior of lookFile is consistent with what is actually happening, but not with what you expect
15:23:03 <stepcut> it would be easier to fix lookFile if i knew the reasoning behind the current browser behavior
15:23:13 <stepcut> perhaps it is some stupid flaw in the html spec
15:23:34 <kstt> naah, impossible ...
15:23:35 <kstt> :)
15:24:16 <kstt> checking file name for the empty string should be ok so ?
15:24:53 <stepcut> yeah, that is what i do
15:25:02 <stepcut> though, there are two file names involved, so check the right one
15:25:08 <stepcut> the tmpFile name will never be null
15:29:35 <kstt> sure :)
15:30:09 <kstt> this tip is a good candidate for the haddock docstring or the excellent tutorial
15:30:28 <stepcut> yes
15:30:36 <stepcut> or we could fix it in 8 :)
15:32:01 <kstt> or both :) A 1 line warning in the docstring take 30 seconds, commit included
15:32:13 <donri> patches welcome ;)
15:36:54 <kstt> yes, but although I am sure it is truely brilliant, I can't learn darcs at the moment
15:37:25 <kstt> I really wish I had time for that
15:38:39 <stepcut> darcs get url  -- gets source from a url, darcs pull  -- updates source, darcs whatsnew -- shows changes in the local directory, darcs record -- records your changes, darcs send -- emails me the patches!
15:38:47 <stepcut> congrats! You are a darcs expert now!
15:39:14 <kstt> I dislike git interface, but I love the fact that contribution becomes incredibly fun and easy when working though github
15:39:24 <kstt> stepcut: looks easy enough, let's try
15:40:11 <stepcut> except that darcs send only works if you have sendmail configured properly, so usually you have to do, darcs send -O /tmp/patch-name.dpatch, and then attach that to an email
15:40:42 <stepcut> going to move to happstack a github style fork+pull request model soon
15:40:56 <kstt> ?
15:41:47 <kstt> it is copying patches ...
15:42:30 <kstt> stepcut: are you going to move the happstack codebase to github ?
15:43:11 <stepcut> kstt: I would like to mirror it there, but I have no desire to use git
15:54:48 <kstt> sent
15:55:13 <kstt> the patch file weight 50 kB for a 4 lines patch :)
15:57:37 <donri> darcs includes a "context" to make the commuting patches work
15:57:55 <donri> IIUC
15:57:57 <stepcut> :)
15:59:24 <donri> we should have a contribution guide on the site
16:03:09 <stepcut> donri: yeah, the old site had a mini-guide on how to make a darcs patch and send it to us
16:03:16 <stepcut> donri: need to add that back
16:03:32 <stepcut> donri: but, I am hoping to change that process in the very near future, so..
16:04:25 <donri> :)
16:05:51 <donri> i like how it works on darcsden... patches available in forks are automatically listed in the forked repositories darcsden page
16:07:10 <stepcut> neat
16:07:17 <donri> though you still have to fork from the website... would be nice if darcs could have some sort of plugin system where support for such sites could be added and work purely from the command ilne
16:07:27 <stepcut> yeah, I was thinking the same thing
16:07:35 <stepcut> darcs fork ; darcs pull-request
16:08:07 <donri> well, not sure about pull requests... the point with the darcsden approach is that it works without those... for better or worse
16:08:36 <stepcut> well, the point of the pull request is tell the upstream that you want them to take action
16:08:50 <stepcut> actively rather than passively..
16:09:10 <stepcut> but.. maybe I don't understand
16:09:17 <donri> yea... but if you write properly "isolated" patches each patch should more or less correspond to a pull request?
16:09:48 <donri> the pull-request system of github is sort of built on assumptions in git where cherry-picking isn't as streamlined
16:10:50 <stepcut> seems like you still want to be able to explicit notify the upstream that you are ready for your patches to be integrated.. but you don't want them to be emailed everytime you push a patch to your repo
16:11:04 <donri> maybe :)
16:11:13 <donri> something in between darcsden and github
16:11:15 <stepcut> so, there is a difference between showing that there are unpulled patches, and getting a request to pull now please
16:13:20 <stepcut> kstt: your patch has been applied and is pushed to the live site. It will be in next happstack-server release on hackage. No schedule for that yet.
16:13:21 <donri> in github pull requests are bug tickets now... so perhaps something like that, with "spontaneous branches"...
16:13:27 <stepcut> kstt: thanks!
16:13:40 <donri> though i think i'd prefer darcs to have something like bazaar instead of the regex searching commit messages...
16:14:04 <stepcut> donri: I think there is value in trying to make it github-like as sensible
16:14:12 <donri> bazaar is integrated into launchpad (via a plugin) and tracks metadata for tickets in commits so you can do like, bazaar commit --fixes lp:bugid
16:14:59 <donri> so instead of pull-requests, perhaps open a ticket in upstream and then push patches to your fork with metadata associating the patches with that ticket
16:15:33 <stepcut> yeah
16:55:10 <donri> stepcut: i think for github-like, mirroring if it can be done properly is the best option. otherwise, i think it's more interesting to get it right, and right for darcs. :)
16:57:23 <stepcut> well, right for darcs is getting git users :p
16:57:33 <donri> haha
17:53:56 <donri> i want an ixset with invariants enforced such as uniqueness of indices
17:54:29 <donri> logically i'd model this data with a Map but then you don't get indexing
17:54:49 <donri> ^W arbitrary indexing :)
17:55:41 <stepcut> yeah
17:55:46 <stepcut> we need something better than ixset
17:56:25 <donri> practically, it just means I use updateIx instead of update, but i don't like that i can get that wrong :)
17:56:50 <stepcut> yup