18:26:04 <stepkut> donri: today could be the day!
18:26:15 <donri> rejoyce!
18:27:16 <donri> rejoice, apparently. stupid not-lojban english.
18:30:43 <stepkut> oh, I thought it was a pun
18:31:21 <donri> no, i just suck at english :)
20:08:14 <dino-> I am running into difficulty with trying to get the entire request body as a big ByteString or whatever. Doesn't really matter what.
20:08:28 <dino-> I started with a Happstack.Lite, converted it to .Server
20:08:40 <dino-> Doing the decodeBody, and then getData
20:09:07 <dino-> And just trying to print what comes back. Running into no instance of FromData.
20:09:28 <dino-> Having trouble finding any examples of grabbing the whole body. Not those look* functions, all of it.
20:09:41 <stepkut> yeah, getData is trying to decode the body as multipart/form-data, if you want the raw undecoded data, you need to use getRequestBody
20:09:51 <stepkut> I think that is what it is called, one moment
20:13:40 <stepkut> http://www.happstack.com/docs/happstack-server-7.0.2/doc/html/happstack-server/Happstack-Server-Types.html#v:takeRequestBody
20:14:10 <stepkut> so, you can only take the request body if it has not already been decode by 'decodeBody', otherwise we would have to keep the whole request body around in RAM, just in case
20:14:41 <stepkut> however, decodeBody will only touch the request body if it has the content types 'multipart/form-data' or the x-url-encoded one
20:14:41 <dino-> Ah, ok
20:15:06 <dino-> Ok, so no decode in this case.
20:15:09 <stepkut> so, for 'application/json' it would leave it alone
20:15:49 <dino-> And that call gives me back a RqBody which is instances into Show and looks like has a ByteString inside
20:16:22 <dino-> But you're saying I shouldn't use decodeBody at all? My data is actually some XML that I'll be snarfing with TagSoup here.
20:17:20 <stepkut> you don't need decodeBody for what you are trying to do right now. Calling it should not cause any problems in this particular case though.
20:18:26 <stepkut> decodeBody is only required if you want to use the look* functions
20:18:55 <dino-> Ok. Thank you.
20:26:35 <dino-> Wait, I don't understand how to get the Request to pass to takeRequestBody
20:27:12 <donri> why tagsoup for xml
20:27:25 <stepkut> askRq
20:27:47 <stepkut> (RqBody body) <- takeRequestBody =<< askRq, i think
20:29:01 <dino-> donri: It's quick for grabbing small things as opposed to, say, hxt. No?
20:29:34 <donri> ok :)
20:30:08 <dino-> stepkut: Ah, ServerMonad
20:30:21 <dino-> It's like a State or Reader in there.
20:30:22 <dino-> thank you
20:30:24 <stepkut> yeah
20:30:32 <donri> dino-: ServerPart is an instance of that btw
20:30:36 <stepkut> right now ServerMonad is basically, ReaderT Request
20:31:10 <LambdaDusk> someone proposed a new HTTP error code of 451, will happstack support it soon?
20:31:34 <dino-> The data-has-been-censored response?
20:32:15 <LambdaDusk> yeah, I have the feeling it will be increasingly important soon
20:32:22 <dino-> donri, stepkut: Ok. I need to read more about the achitecture of the happstack. Today has been just hacking at the -lite example. Now gotten into the weeds with it.
20:32:50 <donri> LambdaDusk: you can setResponseCodeM or whatever any number I think
20:32:58 <LambdaDusk> ah yes
20:33:15 <stepkut> dino-: have you already read the crash course?
20:34:24 <dino-> stepkut: Not much, been poking at the crash course to (try to) figure this stuff out
20:35:06 <LambdaDusk> I have started writing a tutorial for Happstack recently
20:35:25 <donri> cool!
20:35:52 <LambdaDusk> well, happstack/acid-state together
20:36:08 <LambdaDusk> because I feel happstack is a perfect fit for HTTP-APIs
20:39:33 <donri> i think we could improve the support for restfulness, i.e., it's already possible but could probably be made nicer (e.g. helpers for dispatching based on Accept header)
20:40:35 <dino-> All this works now, thanks. I will go through the crash course next.
20:40:47 <stepkut> sweet!
20:40:58 <stepkut> LambdaDusk: nice!
20:41:25 <LambdaDusk> but good to know that decodeBody will not work with JSON
20:41:27 <stepkut> LambdaDusk: be sure to document the stuff we could change in 8 to make it even better. Everything is up for grabs
20:41:52 <stepkut> LambdaDusk: yeah, it should ignore anything that doesn't look like form submission data
20:42:25 <stepkut> LambdaDusk: I am experimenting with an request data arrow that could make that is less funky..
20:42:27 <LambdaDusk> stepkut: I am not far, just wrote the introduction - been spending the time with building the application for the tutorial
20:42:37 <stepkut> you can actually apply quotas to individual fields and stuff :)
20:43:03 <LambdaDusk> I have been working on an happstack-clone with arrows ^^ only out of interest, though
20:43:24 <stepkut> LambdaDusk: fun
20:43:28 <stepkut> I am interested ;)
20:43:46 <stepkut> I am going to release a blog post soon about Happstack and the Free monad
20:44:04 <LambdaDusk> Prompt is also an interesting monad
20:44:39 <LambdaDusk> oh and also I have experimented with an oauth2 server implementation for happstack
20:44:57 <stepkut> ooo
20:44:59 <stepkut> epic
20:45:12 <LambdaDusk> I wish I was able to stick to things for more than a few hours, though :(
20:46:40 <LambdaDusk> it is strange that there are dozens of oauth client implementations in every language, but hardly any oauth server libs
20:50:07 <LambdaDusk> anyway, the oauth2 server app for happstack... I have huge problems finding a good generalization
20:50:39 <stepkut> ugh
20:52:15 <LambdaDusk> ?
20:53:10 <stepkut> in regards to 'huge problems'
20:54:12 <LambdaDusk> It's my problem generally =/ I am sure it's simple but I can't find an idea
20:54:56 <LambdaDusk> one problem is that OAuth2 allows for 4 authentication methods, each needing different callbacks for the validation
20:55:03 <stepkut> joy!
20:55:37 <LambdaDusk> and the server can choose which to implement... I thought about a data-thingie with lots of Maybes, but that's ugly
20:58:09 <LambdaDusk> A State monad could do it
22:04:58 <drakej> Converting over from -lite, and I am wondering where I get msum from
22:06:53 <drakej> Control.Monad seems to fix that part
22:07:53 <stepkut> yeah, Control.Monad
22:13:43 <drakej> ok, converting the -lite compiles. Just need to work out some bugs.
22:14:18 <drakej> on /form from -lite: Server error: lookInput msg failed because the request body has not been decoded yet. Try using 'decodeBody' to decode the body. Or the 'queryString' filter to ignore the body.
22:15:45 <stepkut> yeah, one moment
22:16:06 <stepkut> I should really make a guide on what you need to do to switch
22:16:15 <stepkut> there is not much, but documenting it would make it even easier :)
22:16:36 <stepkut> http://www.happstack.com/docs/crashcourse/RqData.html#rqdatapost
22:30:12 <drakej> thank you looking at it
22:30:46 <stepkut> no problem!
22:41:46 <drakej> Would it be reasonable to make this thing just with runhaskell for development?
22:43:26 <stepkut> yup
22:43:27 <stepkut> I do
22:46:49 <drakej> Is it normal to occassionally get HTTP request failed with: shutdown: invalid argument (Socket is not connected)
22:48:36 <stepkut> drakej: yeah, sometimes the remote side decides to close the connection first
22:51:22 <drakej> I am just simply rewriting this thing using the stuff I need. This crashcourse is easy to follow :-). Thanks be to the writer(s).
22:52:32 <stepkut> thanks!
22:58:41 <dino-> stepkut: Could just add that, import Control.Monad and I forget what the other thing was right to the -lite lhs page. I think it's literally two more tiny things.
22:59:39 <dino-> I think it was not as straightforward as just swapping serve for simpleHTTP
23:00:04 <donri> you need at least msum
23:00:05 <dino-> That was the other thing I think. You have to give it a conf
23:00:20 <donri> yep, nullConf instead of Nothing
23:04:30 <stepcut> better? http://www.happstack.com/C/ViewPage/9
23:04:51 <stepcut> oops, minor formatting issue
23:06:52 <dino-> Something like this: http://ui3.info/d/misc/happstack-lite-edit.html
23:07:07 <dino-> Oh! You did it too
23:07:12 <dino-> sorry
23:07:29 <stepcut> no worries!
23:07:36 <dino-> Doesn't it have to be simpleHTTP nullConf ?
23:08:02 <stepcut> yes, that is what I meant to be typing
23:08:28 <stepcut> my useful thinking period for the day is over
23:08:36 <dino-> Ah, you have to have that decodeBody when you go from lite to regular-strength? I was shaky on that one.
23:08:43 <stepcut> yeah
23:08:45 <dino-> Because it no longer gets done all the time
23:08:50 <stepcut> lite calls it implicitly
23:08:52 <dino-> ok, I'll need that too
23:08:54 <stepcut> yeah
23:09:03 <stepcut> I want to try to unify these differences in 8
23:09:15 <dino-> for other things unrelated to the all-of-the-request that I have to add
23:09:26 <stepcut> in 8, you should not have to do anything *except* switch Happstack.Lite to Happstack.Server I hope
23:10:43 <donri> i think we should use data-default instead of Maybe or the nullBla pattern
23:10:56 <stepcut> maybe
23:11:05 <stepcut> I am not thrilled by data-default
23:11:27 <stepcut> pins you down to one possibility
23:12:04 <donri> well you can still use record update syntax or provide alternatives as exports
23:15:28 <donri> i think the name is a bit misleading, Default is meant for "empty" values
23:15:59 <donri> i suppose you could argue that doesn't work well for ServerConf because then you get like, port = 1, decodeBody 0... :P
23:16:05 <stepcut> well, that is part of what I don't like about Default.. it is not really clear what it means
23:16:48 <stepcut> for simpleHTTP we already have several different configs. The poorly named, nullConf, but also validateConf
23:17:28 <stepcut> yeah
23:18:25 <donri> we could still use Default and define the others in terms of that.... depending on whether that gives us anything
23:19:52 <stepcut> what is the point of a class here?
23:19:55 <donri> or we could provide a new class for "actual" defaults...
23:20:30 <donri> stepcut: if you write a new config from scratch, you don't need to fill in values for fields you're not using ... and don't need to import lots of nullBla stuff everywhere
23:21:21 <donri> i like to use Default for acid-state so i can just do openLocalState def...
23:23:34 <stepcut> i can see Default being more useful for acid-state
23:23:44 <stepcut> not so sure about simpleHTTP yet
23:25:32 <donri> for my app that uses happstack + ircbot you end up with at minimum three nullBla that has to be imported and written out where the type or field name already makes it obvious.... and two more for each bot i connect (multiple networks)
23:25:46 <donri> well ok, the other bots can use the same nullBlas
23:26:24 <donri> so perhaps not data-default for configs, but maybe some new class?
23:26:34 <stepcut> I am too mentally tapped to think about this today. But seeing real world examples would certainly help
23:28:09 <donri> i don't have a good example handy (rewriting that app from scratch, hah)
23:28:31 <donri> duno if you notice it less with your approach of using getopt to create configs
23:28:55 <donri> but imagine using dyre... you're using record syntax as a sort of configuration format and you want it to be as little noisy as possible
23:30:18 <donri> config = def { httpConfig = def { port = 80 }, botConfigs = [def { user = def { username = "robocop" } }] }
23:30:52 <donri> config = nullConfig { httpConfig = nullConf { port = 80 }, botConfigs = [nullBotConf { user = nullUser { username = "robocop" } }] }
23:30:59 <donri> shrug :)
23:31:05 <donri> just think a type class makes it nicer
23:31:53 <donri> same thing with the *BS functions in happstack-server... although you hinted they might be gone in h8
23:32:31 <tazjin> Just saw the clckwrks announcement, looks pretty cool
23:34:11 <stepcut> tazjin: thanks! I hope it will be!
23:34:43 <tazjin> I just honestly wish you would use Github for version control, I think it's a lot easier to use for collaborative coding, issue tracking etc. :/
23:35:30 <donri> i think the plan is to have such features in clckwrks itself using darcs / scoutess
23:36:35 <stepcut> tazjin: are they going to add darcs support soon ?
23:36:45 <tazjin> I don't think so
23:37:26 <stepcut> if github is the only good thing about git, then clearer github + darcs would be even better :)
23:38:02 <stepcut> but I do plan to see just how unusuable darcs bridge is
23:38:11 <tazjin> I agree, but I sincerely doubt that *git*hub is going to add anything besides git anytime soon ;P
23:41:53 <stepcut> donri: I'll read the irc log tomorrow and figure out what you are talking about. my brain is OFF for the rest of the day.
23:42:50 <luite> oh cool source code released!
23:42:58 <luite> finally ;)
23:43:15 <stepcut> :)
23:43:27 <stepcut> yeah
23:43:35 <stepcut> now I just have to make it pretty :)
23:43:47 <stepcut> released, and something I am proud of, are not yet the same
23:44:11 <stepcut> though, there are certainly good parts, just not all good parts yet
23:46:58 <tazjin> Well, the lack of PHP already makes it better than Wordpress ;P
23:47:08 <stepcut> :)
23:47:12 <stepcut> yeah
23:47:21 <stepcut> the plugins stuff is definitely not right yet
23:47:33 <stepcut> and the lack of page slugs makes things ugly
23:48:08 <stepcut> but, the first bug to fix is probably fixing the blog stuff so that it uses the draft state instead of going straight from non-existent to published
23:48:20 <stepcut> I also need to clean up the formatting and add comments