04:54:02 <indeed> I tried to access form data from selection list with multiple selected elements. I tried to use "looks" for this purpose, but i get only [] back. Is there an other way to access these data?
04:54:06 <indeed> http://pastebin.com/2YU5tDTX
11:21:11 <donri> @ask stepcut to merge http://paste.pocoo.org/raw/CPcBpzi7fgFeWY7rAwhD/ if he feels like it mkay
11:21:11 <lambdabot> Consider it noted.
14:05:24 <McManiaC> stepcut: is it possible to make these "HTTP request failed with…" messages more verbose, mainly with information about the requested path and time/date of the request?
14:10:38 <McManiaC> stepcut: also, would a segmentation fault in a request-thread be caught by happstack?
14:11:39 <McManiaC> guess not
14:11:40 <McManiaC> :)
16:35:44 <stepcut> McManiaC: I'll look and see..
16:35:45 <lambdabot> stepcut: You have 1 new message. '/msg lambdabot @messages' to read it.
17:59:03 <donri> stepkut: "ok" overrides composeFilter; bug or feature?
18:01:56 <stepkut> overrides everything ? or just the response code?
18:02:01 <donri> code
18:02:28 <donri> i have a filter for handling etags; "ok" made it return empty response with code 200 :P
18:02:53 <stepkut> if ok is the last filter applied, then it would make sense for it to override any other response codes?
18:03:08 <donri> so "ok" is a filter itself?
18:03:13 <stepkut> yes
18:03:17 <donri> ok :)
18:03:18 <stepkut> you can actually do, ok ()
18:03:28 <stepkut> do { ok () ; return (toResponse "foo") }
18:03:40 <donri> i'll just not use "ok" and return the response instead
18:03:45 <donri> yea
18:03:48 <stepkut> yep
18:04:19 <donri> "ok" is typically redundant anyway since the default code is 200
18:04:32 <donri> and when it isn't, it's because you want something else
18:04:47 <stepkut> the default is 200, but ok forces it make to 200 if you want to be really sure
18:05:14 <stepkut> that is the point of all the filters like, ok, notFound, internalServerError, etc
18:06:05 <stepkut> do you think there is a more sensible option?
18:06:21 <donri> duno, i was probably using it wrong to begin with
18:06:48 <donri> but perhaps the docs should recommend "ok" less
18:06:53 <stepkut> i think that perhaps it would make more sense if the type of those filters was different
18:07:05 <stepkut> ok :: m () -- filter that sees response code to 200
18:07:23 <donri> yea
18:07:56 <stepkut> I like to use 'ok' instead of 'return'.. seems more meaningful most of the time
18:08:12 <stepkut> it makes it clear that that is where I am creating the 'Response'
18:08:25 <donri> well as you see, it can lead to problems because you might not actually want a 200 ok even if you think you do :)
18:08:49 <stepkut> I would need to understand your use case more
18:09:07 <donri> http://paste.pocoo.org/show/540097
18:11:19 <donri> you know http://en.wikipedia.org/wiki/HTTP_ETag ?
18:14:36 <stepkut> one moment
18:16:54 <stepkut> something like this maybe?
18:16:56 <stepkut> http://paste.pocoo.org/show/540104/
18:17:43 <donri> well my code is already working, but you mean to "escape" from "ok"?
18:21:13 <stepkut> yes.. and more
18:21:20 <donri> doesn't typecheck
18:21:25 <donri> don't i need to do that on the composeFilter itself
18:21:32 <stepkut> ?
18:21:48 <stepkut> oh
18:21:49 <stepkut> i see
18:21:57 <donri> filters are Response -> Response
18:22:04 <stepkut> one moment
18:22:10 <donri> oh you're not using composeFilter
18:22:18 <stepkut> yeah
18:22:27 <stepkut> hold on
18:22:32 <stepkut> it is brokne though
18:22:43 <donri> where are you getting response from then
18:22:51 <stepkut> nowhere, that is the problem
18:22:54 <donri> :)
18:23:04 <stepkut> I didn't have adler32 in scope when I wrot ethat code
18:23:13 <stepkut> so I just wrote, let curETag = undefined
18:23:24 <stepkut> which worked.. but obviously this current code does not
18:24:50 <stepkut> out of batteries. bbl.
18:24:59 <stepkut> this is a bit tricky, but worth solving
18:25:12 <stepkut> would be nice to have an eTagFilter shipped with happstack-server
18:25:23 <donri> yea i plan to polish it up and send you a patch
18:26:43 <donri> i guess it works with "ok" if you add it *after*; I was mistakenly thinking of "ok" as needing to be the final thing in the monad chain but guess not?
18:27:07 <donri> do ok "hi"; eTagFilter -- good?
20:01:53 <donri> nope
20:35:01 <stepcut> I think your workaround is not going to work anyway..
20:35:13 <stepcut> because what happens if you need to do, seeOther..
20:35:33 <stepcut> ? or some code other than 200 that returns a body?
20:36:07 <stepcut> assuming the etags filter *must* run last, the easiest solution might be:
20:36:20 <donri> preliminary https://github.com/dag/kibr/blob/master/src/Happstack/Server/ETag.hs
20:36:38 <stepcut> withETags :: ServerPartT IO Response -> ServerPartT IO Response
20:36:47 <stepcut> simpleHTTP nullConf $ withETags $ route
20:36:47 <stepcut> ?
20:37:09 <donri> perhaps
20:37:26 <donri> i mostly tried to make it like compressedResponseFilter
20:37:49 <stepcut> yeah, but compressedResponseFilter does not change the response codes..
20:37:55 <donri> true
20:38:15 <donri> perhaps something more like ifModifiedSince then
20:40:21 <stepcut> yeah..
20:40:33 <stepcut> though ifModifiedSince doesn't really provide a convenient way to be called at the moment
20:40:39 <donri> yea
20:40:54 <stepcut> it is used internally by the file serving stuff and it made sense to try to expose it to at least some degree
20:41:02 <stepcut> but clearly it could use a nice wrapper or something
20:43:29 <stepcut> the other option might be to just stick a version of eTagFilter at the end of the chain
20:44:53 <stepcut> not quite sure how to do that offhand though
20:45:00 <stepcut> sounds a bit fragile
20:45:15 <stepcut> first I need to read up on etags
20:45:30 <donri> perhaps the order of composeFilter should be inverted
20:46:42 <donri> seems intuitive to think of the filters added first as being "outermost"
20:46:46 <donri> and getting the last say in the matter
20:48:07 <stepcut> hmm
20:48:08 <donri> or am i confused?
20:48:41 <donri> what does compressedResponseFilter >> ok "hi" result in? "hi" should get compressed?
20:48:43 <stepcut> so: do { notFound () ; ok "foo" }, should return 404 ? but with the body "ok" ?
20:48:58 <stepcut> that should compress 'hi'
20:49:13 <donri> but on the other hand setResponseCode 304 >> ok "hi" results in 200 ok?
20:49:20 <stepcut> yes
20:49:37 <donri> aren't these two in conflict then?
20:49:43 <stepcut> no
20:50:08 <stepcut> compressResponseFilter compresses the body and adds a response header. ok sets the response code. Doesn't really matter which order you do those in
20:50:39 <stepcut> if you have multiple filters that set the response code, then the last one be to called is the one that 'wins'
20:50:40 <donri> oh, it doesn't actually set the body
20:50:46 <donri> it's just >> return
20:50:51 <stepcut> yeah
20:51:00 <donri> i guess that's what tripped me up
20:51:17 <stepcut> ok r  =setResponseCode 200 >> return r
20:52:04 <stepcut> I sometimes think that we should change type of ok and friends to be:
20:52:09 <stepcut> ok :: (Happstack m) => m ()
20:52:39 <stepcut> I definitely plan to change dir and path and friends to be monadic like that
20:52:49 <donri> yea that would have confused me less i think
20:52:54 <stepcut> yeah
20:52:59 <stepcut> less confusion is better
20:53:03 <donri> and yea it's weird at the moment how dir and nullDir are different
20:53:06 <stepcut> especially since it gives up no expressive power
20:53:09 <stepcut> yeah
20:53:19 <stepcut> also, I keep trying to use dir as though it were already monadic
20:53:25 <donri> me too :)
20:53:49 <donri> which is also why i think i'd prefer the etag filter to be monadic
20:53:55 <stepcut> it's because dir was written when parts were still an actual list of parts, dir :: String -> [ServerPart a] -> ServerPart a
20:54:00 <donri> it's just that i was using "ok" wrong to begin with
20:54:41 <donri> i also think nullDir should be the default at the end, if that is possible
20:55:10 <stepcut> not really
20:55:20 <donri> but i suspect it's not sanely possible
20:55:35 <stepcut> methodM had a secret internal nullDir.. that just caused problems
20:55:45 <donri> hehe
20:55:47 <stepcut> nullDir also needs a better name
20:55:53 <stepcut> endOfPath?
20:55:54 <donri> yea
20:56:01 <stepcut> I don't really have a good idea though
20:56:23 <stepcut> in snap it is, ifTop.. which seems even more confusing
20:57:12 <donri> is there an inverse of trailingSlash?
20:57:21 <donri> I don't like that /style.css/ is a valid route
20:58:38 <stepcut> hmm
20:58:52 <stepcut> maybe trailingSlash should take a Bool?
20:59:01 <stepcut> trailingSlash :: Bool -> m ()
20:59:58 <stepcut> one of the first tasks after the Happstack 7 release is revisiting all these issues (aka, converting to a more monadic style for dir, ok, etc) and figuring out if there are more powerful dynamic routing combinators that we should be using
21:01:16 <stepcut> that is one of the reasons for releasing 7. During 6 we have made a bunch of smaller, mostly compatible changes. Releasing 7 will switch us over official to acid-state, and also mark the beginning of some more dramatic changes
21:01:17 <donri> +1
21:02:07 <Lemmih> Dramatic changes are the best kind of changes.
21:02:09 <stepcut> fortunately, converting your code from concative to monadic style is pretty straightforward. And we can even provide a backwards compatibility module for the most part
21:02:54 <stepcut> one issue is that you can not do monadic 'dir' combinators right now because the Request is in the ReaderT monad, but we need it to be in StateT
21:03:19 <stepcut> right now dir uses 'local' to modify the reader. But a monidac style needs modify.
21:03:48 <stepcut> that is why things like, nullDir and method can be monadic (they don't modify the request path), but dir and path are not (they consume part of the path
21:03:48 <stepcut> )
21:05:22 <donri> should methodM GET imply HEAD? i don't think it's spec compliant not to
21:06:01 <stepcut> possibly
21:06:45 <stepcut> I have wondered that myself
21:06:57 <stepcut> the right thing would happen if it did
21:07:04 <donri> yea
21:07:18 <stepcut> and you could still provide an alternative 'HEAD' implementation by putting it before the GET
21:08:28 <stepcut> we could also add a, GET_ONLY, that doesn't imply HEAD just in case you really need that for some reason
21:08:54 <stepcut> I'm happy with that solution..
21:09:08 <stepcut> http://code.google.com/p/happstack/issues/detail?id=161
21:09:26 <donri> I also think they should be renamed to not be all uppercase
21:09:40 <stepcut> oh ?
21:10:00 <stepcut> they are uppercase in the spec :p
21:10:06 <donri> yea, all upper case implies they're acronyms
21:10:17 <donri> but we're writing haskell, not raw http :)
21:11:07 <stepcut> because method uses a type class, we could provide both variants :-/
21:11:11 <donri> for example in ircbot you have PrivMsg but the actual command is PRIVMSG
21:11:32 <stepcut> yeah
21:11:37 <donri> and i argue that ircbot is right where happstack is wrong :)
21:12:16 <stepcut> still. the other major haskell frameworks also use uppercase
21:12:16 <donri> "200 OK" is uppercase too, perhaps rename "ok" to "oK" mwahahah
21:12:40 <stepcut> also.. people are used to doing, <form action="/" method="POST" >
21:12:49 <stepcut> so.. they are used to typing it uppercase
21:13:00 <donri> it's not important, just my OCD acting up
21:13:23 <stepcut> but, shouldn't you want it to be consistent with how you have to write it in HTML?
21:13:47 <donri> could also argue all upper has less risk of colliding with an application Post constructor
21:13:51 <donri> for blog posts etc
21:13:55 <stepcut> yeah
21:14:11 <stepcut> I do use Post in the acid-state tutorial :)
21:14:43 <stepcut> all uppercase has the meaning of some type of contstant or enum in 'C'.. which the request methods kind of are
21:15:00 <donri> let's just be all objective-c HTTPMethodVerbPOST
21:15:20 <donri> ...FactoryFactory... no wait that's java
21:15:25 <stepcut> I gotta eat and clean. But I will think more about the etag solution later
21:15:31 <donri> gotta eat too :)