00:00:07 <donri> like, you setHeaderM something and then ok $ toResponse, and "somehow" that header is set on the final response
00:00:18 <donri> i think that's somewhat unintuitive/surprising however useful
00:00:37 <donri> could just be a docs issue of course :)
00:01:09 <stepkut> what could we do instead ?
00:01:27 <donri> duno... setBody instead of toResponse?
00:02:20 <donri> as a monadic action that is
00:04:17 <donri> i suppose toResponse allows it to e.g. set a custom content-type etc...
00:05:59 <donri> it's just that intuitively it seems that setHeaderM and friends modify a default response and then you just go ahead and return a completely new response, so you think that should throw away that original default response
00:07:28 <donri> <spj>does that make sense?</spj>
00:08:06 <stepkut> setHeaderM doesn't modify a default response.. it just adds a filter that will be applied to whatever Response you provide before sending it..
00:08:21 <donri> i see
00:08:37 <donri> i guess i'm still thinking too imperatively
00:08:42 <stepkut> the FilterMonad stuff allows you to add a bunch of filters that will be applied to the Response before it is sent
00:08:55 <stepkut> like adding headers, doing gzip compression, etc
00:09:24 <stepkut> but.. there are problems with that too.. like if you need to apply a filter that is the last one to run.. such as e-tags
00:09:41 <stepkut> you don't get any control over the precedence of filters (right now anyway, that could be changed though)
00:10:13 <donri> why doesn't that matter for compression again?
00:10:16 <stepkut> I think snap uses a model more like what you described.. the 'Response' is stored in a State monad and you can get and set the Response anywhere in your handler
00:11:05 <stepkut> it usually doesn't matter because most of the filters just add headers. compression adds headers and then compresses the body
00:11:14 <stepkut> since no one else is dorking around with the body, there is no problem
00:11:30 <stepkut> but.. I do think there is room for improvement here
00:11:44 <stepkut> one of the things to do is to find cases where the current system fails
00:11:50 <donri> so if you have another filter that does affect the body it could be a problem?
00:12:02 <stepkut> yup
00:12:23 <stepkut> we also need some way to register IO hooks that get run after the Response has been sent
00:12:35 <stepkut> like, if the Response was sending a temporary file that should be deleted..
00:12:49 <donri> yea
00:14:55 <stepkut> so, two basic models are:
00:15:16 <stepkut> user provides a function like: Request -> IO Response
00:15:41 <stepkut> the other model is the user provides a function like: Request -> StateT Response IO ()
00:16:11 <stepkut> like.. in snap you can just call 'writeBS' anywhere and it appends text to the Response body I think
00:16:58 <donri> problem with StateT though is you gotta start out with a default Response, so what do you use for a body? ""? isn't that "risky"?
00:17:25 <stepkut> why?
00:17:46 <donri> well in happstack to send an empty response you have to explicitly ask for that right? with e.g. toResponse ()
00:18:05 <donri> with the other model you could easily forget it and the default would be an empty response?
00:18:44 <stepkut> right
00:19:08 <stepkut> I am not really clear what the appeal of the StateT Response  model is
00:19:53 <stepkut> what other models could we use?
00:21:38 <donri> good question :)
00:22:35 <stepkut> the Request -> IO Response one is attractive, because it clearly shows that the only input is a Request, and that you can't be done until you have created a Response
00:23:14 <donri> do you mean literally a function like that, like raw wai?
00:24:01 <stepkut> no.. we usually wrap that up in monads like, ReaderT Request (MaybeT IO) Response
00:24:11 <donri> yea
00:24:30 <donri> composes better, for e.g. "middleware"
00:24:38 <stepkut> I am also not that thrill about the 'msum' stuff
00:24:49 <stepkut> for composing handlers
00:25:03 <stepkut> seems like it allows too much backtracking by default
00:25:26 <donri> yea, i think for routing web-routes is better anyway and for other things mzero is plain wrong in resulting in 404
00:25:28 <stepkut> typically when a handler matches.. there is no need to backtrack if there is a failure deeper down
00:26:36 <stepkut> a more parsec-like approach where you have to use 'try' might be more sensible
00:26:44 <stepkut> or something like PEG
00:27:15 <donri> ARROWS!
00:27:31 <donri> ACTION has no idea when arrows make sense and not, but, ARROWS!
00:27:35 <stepkut> possibly
00:27:56 <stepkut> arrows make sense for extracting the query_string / request body parameters
00:28:12 <donri> IIRC the original motivation for arrows was better optimized parsers? and yet there doesn't seem to be a maintained arrow parser :/
00:28:38 <stepkut> HXT is the only arrow parser I know of
00:28:48 <stepkut> but, it is more XML, not general purpose
00:28:58 <donri> exactly
00:29:17 <stepkut> there were some other ones
00:29:50 <luite> i've tried hxt, but it felt rather slow...
00:29:58 <stepkut> I feel like Doaitse Swierstra or someone had some arrow based parsers
00:30:11 <luite> and i never got anywhere near the eas of use of css selectors
00:32:38 <donri> stepkut: keyword "had" = not actively maintained?
00:32:44 <donri> http://hackage.haskell.org/package/PArrows
00:34:42 <stepkut> I do all my parsing with Bytestring.takeWhile !
00:35:05 <donri> pff, real programmers pattern match on character lists
00:35:48 <stepkut> actually, I appear to use unsafeDrop, unsafeIndex, and unsafeTake !
00:36:02 <stepkut> plus, elemIndex, split and uncons
00:36:07 <stepkut> http://patch-tag.com/r/stepcut/acme-http/snapshot/current/content/pretty/Acme/Request.hs
00:41:50 <stepkut> I need to figure out how to deal with the javascript file dependencies
00:50:44 <donri> the easy answer is "don't", and is what most people seem to be doing
00:50:49 <donri> they just say "you need jquery"
00:51:50 <stepkut> yeah
00:52:00 <donri> btw in your parseMethod i think the guards are redundant because overloadedstrings translate to that
00:52:04 <donri> in acme-http
00:52:49 <stepkut> I am thinking that I might just have the executable check for the existance of the javascript files, and print a warning if they are missing
00:53:03 <stepkut> on my system, the javascript files are install via debian packaging
00:53:24 <donri> it's not packaged for fedora
00:53:55 <stepkut> yup
00:54:20 <donri> what executable?
00:54:35 <stepkut> for happstack-dot-com
00:54:44 <donri> ah
00:55:39 <donri> i think the pros use make-like deployment systems where you can depend on a system package being installed
00:55:46 <donri> "puppet"?
00:57:02 <donri> https://en.wikipedia.org/wiki/Configuration_management
00:59:15 <donri> another thing to reimplement in haskell ;)
00:59:33 <stepkut> I use .debs
00:59:52 <donri> so just depend on the jquery package?
01:00:11 <stepkut> yup
01:00:25 <stepkut> libjs-jquery
01:00:40 <stepkut> cleaning now, bbl.
20:01:12 <donri> sooo, file-embed is about 2.5 times more performant (in rqs) than B.readFile, it seems (remember i can't use sendfile... well i guess i could but not serveFile anyway)
20:03:28 <donri> hm is there a way to get the socket to write a response to in happstack?
20:05:58 <donri> oh, serveFile is implemented via another Response constructor, and that only works for one file. ..
20:06:35 <donri> stepcut: could we have sfFilePath be a list, perhaps?
20:08:08 <donri> then i could make the non-embedding combo-handler use sendfile
20:29:06 <stepcut> possibly
20:31:11 <stepcut> http://code.google.com/p/happstack/issues/detail?id=202
20:38:14 <donri> \o/
20:53:46 <stepcut> :)
22:30:03 <donri> stepcut: soooo, what's next on the todo? i guess we're waiting for nibro for hsp stuff so can't do much more there at the moment?
22:30:26 <stepkut> yeah, he as big project at work, so we won't see any action there for a month
22:30:33 <donri> aha
22:30:49 <stepkut> I am trying to wrap up the release of the site source code
22:30:55 <donri> nice!
22:31:02 <stepkut> the happstack-longpoll stuff needs love
22:31:09 <stepkut> then I am going to look into the issues with acid-state
22:31:25 <donri> what issues?
22:31:26 <stepkut> like.. why does it take so long to read in checkpoint files
22:31:36 <donri> aha
22:31:52 <stepkut> also, it runs out of file descriptions sometimes because it reads in the files too lazily
22:36:53 <donri> stepkut: i take it you saw pipes 2.0 was released?
22:38:26 <stepkut> yes