00:54:01 <alpounet> stepcut, http://www.yesodweb.com/blog/2012/03/cabal-nirvana
03:29:45 <stepcut> alpounet: yeah.. sounds like the beginning of a 'linux distribution' for cabal
03:31:15 <stepcut> anyway.. the real solution is that people should only be allowed to upload packages to hackage if they don't break happstack ;)
03:33:31 <stepcut> but.. related to scoutess.. perhaps we can automatically provide 'known to build' configurations
03:34:23 <stepcut> maybe happstack.cabal could just explicitly pin all the version numbers?
03:48:11 <donri> version pinning has its issues too though
03:48:22 <donri> like not getting security updates
03:53:53 <stepcut> donri: well… this is supposed to be automated version pinning.. if the security updates don't build.. then the only solution is to fix it so that they do ?
03:55:12 <donri> so you're planning on automatically making new releases as soon as a dependency upgrade is released that doesn't fail to build?
03:56:00 <stepcut> maybe?
03:56:02 <donri> that might actually be an idea ...
03:56:13 <donri> happstack-server-7.0.782 :D
03:56:15 <stepcut> we are planning to automatically rebuild against haskell platform anytime anything changes
03:57:33 <stepcut> we can be a bit smarter too..
03:57:45 <donri> though, that might end up breaking *apps* even if happstack itself builds with new dependencies
03:57:59 <donri> if there are api changes that happstack isn't using but an app is
03:58:13 <donri> so might need to restrict that to non-api-breaking upgrades
03:58:15 <stepcut> we do not have to upload a new happstack.cabal everytime something changes.. we could leave a more liberal range by default, and only upload a new version if we decide (automatically) that something needs to be pinned to an older  version
03:58:20 <donri> assuming dependencies follow PVP
03:58:59 <stepcut> PVP, etc, can make life easier.. but ultimately there is no substitute for a human … yet
03:59:25 <donri> yea, it's not really a tool issue in the end
03:59:57 <donri> you can't both have the stability of pinned versions and the security/features of ranges
04:00:46 <donri> not even with automated build verification, as apps can still break
04:01:04 <stepcut> the problem with computer science is that reality always gets in the way of elegant solutions
04:01:11 <donri> :)
04:01:22 <stepcut> the existing of errno is proof of that
04:01:30 <donri> elegance that fails to solve a practical problem is not really elegant at all
04:04:57 <stepcut> :)
04:05:23 <stepcut> computer programming would be so much easier if it wasn't for all those 'edge' cases
04:06:15 <stepcut> like.. writing a parser when the input is (magically) always guaranteed to be perfectly valid and unambigious is so much easier than what we actually have to parse in real life
04:09:06 <donri> try vimscripting... no types, can't even really unit test, even parsing of scripts depend on user settings :D
04:09:18 <stepcut> :)
04:09:45 <stepcut> I tried using eslisp for a while.. but the lack of proper tail recursion made me too sad
04:10:07 <stepcut> I can only right so many wrongs in the world, so I have to just let some things continue to suck :p
04:10:15 <donri> yea
04:10:30 <stepcut> Haskell editing is one of those things
04:10:32 <donri> can't really replace vim and emacs
04:11:11 <donri> yi would've been nice but seems dead? and will always be behind vim and emacs
04:11:26 <stepcut> haskell-mode+emacs gets the job done.. but I am a fortunate enough to have very little experience using xcode, eclipse, etc.. so I have not been spoiled too much by what is actually possible ;)
04:11:46 <donri> i'm making my own "haskell mode" for vim https://github.com/dag/vim2hs
04:12:26 <donri> which is why i'm learning all the peculiarities of vimscripting :D
04:12:39 <stepcut> yeah.. dons is good at starting things.. but not at keeping them going. But that is actually really common -- you will find in the business world that the people who *start* companies, and the people that run them when they are successfull are often very different people
04:12:48 <stepcut> beacuse it requires very different personalities
04:13:12 <donri> true dat
04:13:38 <stepcut> I think there is a new yi maintainer though.. but I have not been following it too closely
04:13:54 <donri> last i tried yi it was awkwardly slow
04:14:06 <stepcut> there is also leksah.. which had some nice ideas last time i tried
04:14:07 <donri> like, actual noticable lag in the interface
04:14:11 <donri> rendering etc
04:14:15 <stepcut> but not enough to make we want to switch from emacs
04:14:31 <donri> i tried to try leksah but gave up when it wanted to compute stuff about my haskell environment for 15 minutes
04:14:38 <stepcut> yeah
04:14:58 <donri> chrisdone's haskell stuff for emacs almost makes me want to give emacs a try
04:14:58 <stepcut> my goal is to make enough money to be able to fund more development on haskell-mode
04:15:10 <stepcut> would be nice to see a haskell-mode GSoC project ;)
04:15:11 <donri> i can even sorta use emacs with evil (vim layer)
04:15:39 <stepcut> but.. that is not sexy enough.. even though practically speaking it could have a wider impact than any other Haskell GSoC project
04:15:56 <stepcut> I can sortof use vim :)
04:16:00 <stepcut> and even a tiny bit of ed
04:16:34 <donri> i'd like to see editor-agnostic tools that can easily be integrated into any editor
04:16:39 <donri> like hare, scion and all those
04:17:01 <stepcut> yeah
04:17:19 <donri> but hare chokes on my haskell files and scion didn't even build last i tried it
04:18:04 <stepcut> a really valuable project would be some online, external tool that did incremental parsing, integration with hoogle, etc., and returned the collected information in a format that made it easy to integrate into vim, emacs, etc
04:18:31 <donri> i'd like a tool to "fixate" a source file, like, filling in type signatures and making imports explicit, based on how ghc interprets the original
04:18:34 <stepcut> any something that used extensible parsing so that integrating things like hamlet, HSP, etc, would be easy
04:18:56 <stepcut> yeah, automatic management of explicit imports would be super awesome
04:19:10 <stepcut> we should add this to, http://code.google.com/p/happstack/wiki/GoogleSummerOfCode
04:19:19 <donri> it's probably not even all that difficult to make with the ghc apis or whatever
04:19:48 <donri> a little above my convenience level still
04:19:53 <stepcut> :)
04:20:20 <stepcut> oh the things I could do with a million dollars to spare :p
04:20:27 <donri> :D
04:20:46 <donri> we should have something like the perl foundation grants
04:21:01 <donri> i mean the haskell community at large
04:21:10 <donri> but not enough corporate/financial interest i guess
04:21:15 <stepcut> not yet anyway
04:21:25 <stepcut> but probably in the next 5 years
04:21:34 <stepcut> maybe 10..
04:21:55 <stepcut> it's a bit odd to realize that I have been using haskell as my primary programming language for 10 years already :-/
04:22:33 <donri> 4-5 months for me ;)
04:22:49 <stepcut> :)
04:23:00 <donri> not sure i've even been *programming* for 10 years yet...
04:23:20 <donri> first exposure was to c++ at about age 12... so i guess a little more than 10 years if you count that
04:23:42 <stepcut> That is one of the things that makes it tricky for me to write the happstack crash course.. I forget that many people do not automatically think like expert Haskell programmmers who merely need to know about the specifics of Happstack :)
04:23:56 <donri> i think you've done good so far
04:24:09 <stepcut> yeah
04:24:27 <stepcut> I try to assume that people understand the basics of H98
04:25:10 <donri> well the point of the crash course is to teach happstack, not haskell, i'd think
04:25:16 <stepcut> and common things like MPTC
04:25:16 <stepcut> exactly
04:25:31 <donri> though maybe happstack-lite can teach haskell too
04:25:32 <stepcut> I should add something to preface that refers people to learn you a haskell for great good, etc
04:26:01 <stepcut> I think that a 'Introduction to Haskell via Happstack' could actually be a really good book -- but I just don't have the time to write it
04:26:52 <donri> i find that the best way to learn a language is to do something real and practical rather than silly boring example code
04:27:10 <donri> so yea, separate from the crash course, that's not a bad idea in itself
04:27:12 <stepcut> exactly
04:27:54 <stepcut> I started a blog a long time ago, but will probably never updated it, http://learnhaskell.blogspot.com/
04:28:14 <stepcut> but I still get comments on it now and then even though it is 5 years old :-/
04:29:10 <donri> oh shit 2007 was five years ago
04:29:12 <donri> time flies
04:29:16 <stepcut> yeah...
04:29:52 <stepcut> It's hard to remember actually what things were like 5 years ago, or predict what things will be like 5 years from now
04:30:02 <stepcut> even though 5 years can seem to pass quickly
04:30:24 <donri> hmm ubuntu 7.04 ...
04:30:33 <donri> that was like, windows 95
04:31:32 <stepcut> :)
04:32:10 <stepcut> 5 years ago I worked for Linspire.. a failed Linux distribution company :p
04:32:46 <donri> i think i used arch linux back then, with an e-penis enlarging dwm setup or somesuch
04:32:59 <stepcut> heh
04:33:11 <donri> look ma', no mouse!
04:33:12 <stepcut> i still use xmonad
04:33:18 <stepcut> on OS X even !
04:33:44 <donri> i never used xmonad but it'd probably be my choice today for a tiled wm
04:33:48 <donri> but dwm was just silly...
04:34:01 <donri> hipster show off sillyness
04:34:03 <stepcut> heh
04:34:07 <stepcut> I never used dwm
04:34:28 <donri> it was 2k lines of C code that you configured by editing a .h and recompiling
04:34:52 <donri> not with anything like xmonad's dyre-like functionality, mind you
04:35:02 <donri> proper manual recompile and restart X
04:35:16 <stepcut> well.. xmonad didn't always have dyre-like functionality :)
04:35:32 <stepcut> I started using xmonad around 2-3 weeks after the first release I think
04:36:14 <stepcut> ACTION is still waiting for xmonad with compviz awesomeness :p
04:39:09 <stepcut> http://code.google.com/p/happstack/wiki/EditorAwesomeness
05:13:10 <donri> well, the syntax highlighting in my vim2hs is quite good already, and haskell-mode for vim does the third bullet point
05:14:30 <stepcut> yeah, there is some emacs integration that does type signatures, hoogle integration as well
05:14:48 <stepcut> haskell-mode highlighting is fine for plain haskell.. but not mixed mode
05:14:59 <donri> mixed mode?
05:15:10 <stepcut> haskell + html + css
05:15:11 <donri> you mean like jmacro and hsp?
05:15:20 <stepcut> yeah
05:15:41 <donri> that's how i got started making vim2hs, and mostly works good already
05:15:44 <stepcut> emacs has this idea of mixed mode where you can switch between different editing/highligting modes in the same document
05:16:00 <donri> i've heard rumors that emacs is not as good at embedding languages but not sure how true
05:16:11 <stepcut> dunno
05:20:20 <donri> i'd like to have on-the-fly syntax checking and linting though
05:20:31 <stepcut> yeah
05:20:35 <donri> ghc-mod?
05:21:05 <stepcut> updated :)
05:21:53 <donri> https://github.com/chrisdone/haskell-emacs
05:23:05 <stepcut> yeah, I have not had time to try that
05:23:23 <stepcut> for me the single biggest improvement has been that GHC 7.4 tells you when you mistype something but almost got it right
05:23:45 <donri> it does spell checking of identifiers?
05:24:48 <stepcut> yeah
05:24:52 <stepcut> which is awesome
05:25:13 <stepcut> if you mistype an identifier it says, "Perhaps meant one of theses identifiers from these modules??"
05:27:04 <donri> it should say "are you barking mad, wtf is 'mapN_'?? surely you mean mapM_!"
05:27:25 <stepcut> :)
05:27:41 <stepcut> "my brain exploded" is still the best error message, IMO
05:27:54 <donri> lambdabot?
05:28:09 <stepcut> no, ghci
05:28:16 <stepcut> ghc
05:28:23 <stepcut> when you do something it really doesn't like
05:28:53 <stepcut> mostly only happens when you are pushing the boundaries of new compiler extensions -- where even the authors are not quite sure what should happen
05:28:59 <donri> oh yay on the fly hlint working
05:29:07 <stepcut> the idea is that you should file a bug with a concrete case so they can think about it more :)
05:29:11 <donri> nice errors for the template haskell included
05:29:42 <donri> "the impossible happened"
05:29:51 <stepcut> yeah
05:29:54 <stepcut> that is anohter great one
05:31:46 <donri> kernel panic!
05:46:28 <stepcut> bah.. don't talk to me about Linus :p
05:47:01 <stepcut> if he had listen to Andrew Tenenbaum kernel panics wouldn't exist ;)
05:47:43 <donri> not really a linux invention though are they
05:48:15 <stepcut>  no.. but Linux made them famous :)
05:48:28 <stepcut> well, blue screen of death is basically the same thing
05:48:37 <stepcut> by a different name
15:19:24 <uniquenick> yesod's benchmark page from last year says "in the near future, Happstack will be switching over to WAI/Warp"
15:19:32 <uniquenick> is that still true?  or was it ever true?
17:04:53 <stepcut> uniquenick: we will be examining that in a few weeks
17:05:01 <stepcut> uniquenick: after Happstack 7 is released.
17:05:08 <stepcut> uniquenick: one moment
17:06:11 <stepcut> uniquenick: there is a translator that allows you to use the existing happstack with wai, more details here, http://code.google.com/p/happstack/issues/detail?id=29
17:07:27 <stepcut> uniquenick: the choices we will look at are: using WAI with warp, using WAI with a different backend, or using something based around pipes
17:08:40 <uniquenick> are there any particular concerns about using warp?  I assume the reason to consider it is performance?  but I don't know much about the various haskell webservers, does it have any downsides?
17:12:53 <stepcut> well.. I think the primary reason we would consider it is for speed.. but there is nothing magical about how it gets that speed. And a backend, like warp, is less than 1000 lines of code.
17:13:24 <stepcut> so the question is, do we want to be subjected to whatever gyrations yesod is upto just to use 1000 lines of code
17:14:17 <stepcut> so, we need to look at a bunch of questions.. like, do we think pipes are better than conduits
17:14:37 <uniquenick> warp is fast because of some little trick?
17:14:42 <stepcut> and what features might we want in the backend that warp does not provide
17:16:54 <stepcut> uniquenick: I wouldn't say it is a trick.. warp does not use parsec or attoparsec to parse the http request.. it just uses the low-level ByteString manipulation functions
17:17:10 <stepcut> uniquenick: I have implemented similar parsers myself and gotten similar speeds
17:18:58 <uniquenick> so, snap or happstack could get performance on par with yesod relatively easily without using warp?
17:19:16 <stepcut> yes
17:19:51 <stepcut> especially since the code for warp is available for inspection
17:21:46 <uniquenick> I kinda get the impression that yesod is the outcast in the haskell web world, and snap and happstack get along more?  is that my imagination?
17:23:42 <stepcut> I'm not really sure what you mean by that
17:50:39 <uniquenick> I'm not really sure either, that's what I mean.  I just sort of get the impression that snap and happstack people get along better than they do with the yesod guys
18:08:04 <mightybyte> uniquenick: I think the Snap and Happstack people share more common values.
19:03:34 <alpounet> indeed