00:10:04 <alpounet> ACTION is more into blues these days
00:25:24 <donri> ACTION <- norwegian black metal
00:29:15 <bitonic> donri: relevant: http://3.bp.blogspot.com/-zXJ9jUu1aAY/T3N6jfz86II/AAAAAAAAR6o/I5skdsxSmQI/s1600/MetalBands.jpg
00:29:37 <donri> but yes that song you linked is real nice
00:29:54 <donri> heh, that's true statistics eh
00:32:14 <alpounet> uh, the CIA in the sources
00:39:10 <donri> http://youtu.be/Dq_4LYohOf0 have some more violin fun
01:02:20 <donri> i want to learn to play http://youtu.be/3ZPzilwkOK0
01:02:32 <donri> stepcut: you up to the challenge? :D
01:05:31 <donri> hsp makes me avoid do notation. maybe that's a good thing.
01:20:44 <stepcut> oh nice! once I get my chops back up I really want to study klezmer and russian folk
01:21:55 <stepcut> and gypsy
01:22:07 <stepcut> http://www.youtube.com/watch?v=1bQmT1EM0Eg
01:24:22 <donri> i just realised you don't need forM with hsp, lists are EmbedAsChild
01:26:08 <mightybyte> This has always taken the cake for me as far as violin pieces go.
01:26:10 <mightybyte> http://www.youtube.com/watch?v=KGVgglkA6_U
01:27:33 <stepcut> donri: yup
01:28:00 <donri> mightybyte: i think i've played that
01:28:58 <donri> http://youtu.be/xir-5oAWxXE more good sarasate
01:31:47 <mightybyte> donri: Seriously?  I'm impressed.
01:32:33 <donri> it would sound like crap if i tried it today though
01:33:43 <donri> http://youtu.be/E4bM_zfUTsQ -- ten year old playing my last link, he has the teacher i had ^_^
01:34:09 <mightybyte> Cool
01:34:30 <mightybyte> Yeah, Zigeunerweisen would have been the next Sarasate link I mentioned
01:34:35 <donri> suddenly, i was 14 and thought playing counterstrike was more fun than practicing the violin
01:35:00 <mightybyte> heh
01:35:06 <donri> opium of the masses [of teenagers]
01:35:12 <mightybyte> Yep
01:35:25 <mightybyte> One day in college I played TF2 for 8 hours straight.
01:35:37 <mightybyte> I got done and thought, "What in the world just happened to my day"
01:36:22 <donri> is that the worst you can deliver
01:36:35 <donri> never been to a week-long stay-awake lan?
01:36:46 <mightybyte> Pretty much
01:36:49 <donri> ;)
01:36:50 <mightybyte> I'm pretty tame
01:43:03 <donri> stepcut: what... was that!?
01:45:09 <donri> http://youtu.be/59YGuqaWJDQ have some oblivion
01:47:04 <stepcut> :)
01:48:57 <donri> [what i think of every time they mention the memory charm in hpmor]
01:54:54 <HugoDaniel> stepcut:
01:55:09 <HugoDaniel> in the roadmap page a slight typo in the "We also working on a new project:"
01:55:15 <HugoDaniel> there is a missing "are"
01:56:08 <stepcut> fixed!
01:56:20 <stepcut> thanksÂ… you can see why I use a type-checked programming language :p
01:58:00 <donri> or maybe using a strongly typed language has made you less careful ;)
02:00:31 <HugoDaniel> also
02:00:33 <HugoDaniel> in the website
02:00:46 <HugoDaniel> it would be cool if context sensible urls could be produced
02:01:12 <HugoDaniel> so, have www.happstack.com/roadmap instead of http://www.happstack.com/C/ViewPage/7
02:01:20 <stepcut> HugoDaniel: coming soon..
02:01:25 <HugoDaniel> great :D
02:02:16 <HugoDaniel> replication and sharding for acid-state is going to kick the arse of all other dbms's
02:04:55 <stepcut> :)
02:08:01 <dsfgsdfg> I was looking at Happstack tonight in order to implement a lightweight webdav server solution - However it seems that some of the HTTP verbs for webdav are not supported.
02:08:14 <dsfgsdfg> Is there any way to add support for verbs like PROPFIND?
02:09:56 <stepcut> hmm
02:10:29 <dsfgsdfg> Looking it over, it seems like this would be a change at the library level, since the basic method type is limited to a selection of verbs.
02:10:44 <stepcut> yeah
02:10:50 <stepcut> I think there might be an open bug on that
02:11:27 <stepcut> I don't see one, let me add that
02:12:16 <dsfgsdfg> Otherwise, the new release looks really nice
02:12:41 <stepcut> it should not take long to add support for that
02:13:14 <stepcut> I think we would add an additional constructor like, OtherMethod Text, and some way to use that with MatchMethods
02:13:28 <stepcut> I'll look at it in the morning
02:13:50 <dsfgsdfg> nice
02:14:08 <stepcut> http://code.google.com/p/happstack/issues/detail?id=185
02:15:04 <dsfgsdfg> sweet
02:15:25 <dsfgsdfg> Thank you - that answers my question, and I'll keep an eye on the bug
02:18:32 <stepcut> we could also just add the webdav verbs directly.. I think that is probably the primary usage case for wanting extra verbs
02:20:13 <dsfgsdfg> That would also be a possibility, though that would probably mean adding MKCOL in addition.
02:22:45 <dsfgsdfg> It owuld probably be a matter of if it's appropriate for all web servers using the stack or not.
02:23:25 <dsfgsdfg> Without it in the main type, currently requests with PROPFIND will trigger an error "HTTP request failed with: invalid request method"
02:23:59 <dsfgsdfg> and a 500 being sent back to the client
02:24:19 <dsfgsdfg> so, that would not necessarily be a bad thing for servers that are not intending to implement WebDAV.
02:24:53 <dsfgsdfg> Though I am not completely familiar with Happstack at the moment to know if there is a overall configuration for allowed methods for a project using the framework.
02:26:16 <dsfgsdfg> Full WebDAV may require the verbs PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK
02:26:37 <donri> if you add the OtherMethod Text version and have the server do that for incoming requests, you could easily do a guardRq to throw errors for any such method if you prefer
02:27:30 <donri> guardRq $ \rq -> case rqMethod rq of OtherMethod _ -> ...
02:28:05 <donri> i vote for having constructors for the real http verbs and a catch-all for the rest; but I don't do any webdav so what do i know
02:33:10 <dsfgsdfg> that sounds like it should work, presuming that it could be matched on with things like the method call (e.g. method [OtherMethod "PROPFIND"])?
02:33:54 <donri> yea that should "just work" afaics
02:34:57 <donri> could even have your own method type and implement the MatchMethod class
02:36:14 <donri> data DavMethod = PropFind | ... deriving Show; instance MatchMethod DavMethod where matchMethod m = matchMethod (OtherMethod (map toUpper (show m)))
02:36:23 <donri> then you can do, method PropFind
02:36:35 <donri> yay extensible design at the core
02:37:36 <dsfgsdfg> This is assuming the OtherMethod type would be added... I think I follow.
02:37:44 <donri> yep :)
02:37:50 <dsfgsdfg> nice.
02:38:00 <donri> point being you might want a proper type to avoid typos etc
02:38:09 <donri> but we might not want to "pollute" the primary Method type
02:38:18 <dsfgsdfg> makes sense
02:38:36 <stepcut> I am not sure what the harm in polluting the primary method type is here
02:39:06 <donri> depends, if this is only relevant for webdav and it's not a fuckton of methods i agree it's fine
02:39:22 <stepcut> I do like the idea of creating a custom MatchMethod instance though for a custom type
02:39:34 <stepcut> yeah, webdav is the only one I would add to the core I think
02:39:41 <donri> but if adding for webdav means there'll always be people wanting that and that added too, it'd be easy to lag behind
02:40:08 <stepcut> well, so far in all the years I have been using happs/happstack, webdav is the only thing people have ever mentioned :)
02:41:02 <donri> aye :)
02:41:10 <donri> i don't feel strongly about it
02:41:12 <donri> i just like to talk
02:41:17 <donri> have you noticed?
02:41:58 <stepcut> i was thinking that since there is a, MatchMethod (Method -> Bool), instance, you could do, proFind (OtherMethod txt) = txt == "PROFIND", and then do, method proFind
02:42:22 <stepcut> but that was because I missed that fact that you could actually create a WebDAV type too :)
02:42:29 <donri> downside to having them in Method could be that it's less DRY to add failure for DAV methods
02:42:43 <stepcut> yeah
02:43:57 <dsfgsdfg> Is there a default filter on requests?
02:44:21 <donri> well sure you can have propFind = OtherMethod "PROPFIND" and do method [GET, propFind], that also type checks unlike custom type
02:44:24 <stepcut> dsfgsdfg: what sort of filter?
02:44:32 <stepcut> donri: yeah
02:44:49 <dsfgsdfg> looking through the happstack-lite tutorial, there are instances where specific reponses are sent to method GET or method POST.
02:44:53 <stepcut> donri: I was trying to think of places where we require Method explicitly.. and that is a case
02:45:00 <donri> yep
02:45:28 <dsfgsdfg> but if not specified, do the responses get processed regardless of request verb?
02:45:36 <Lemmih> stepcut: Great job on happstack-7, btw.
02:45:36 <donri> yep
02:45:46 <dsfgsdfg> k.
02:45:50 <stepcut> dsfgsdfg: exactly
02:45:57 <stepcut> Lemmih: thanks
02:46:09 <stepcut> Lemmih: I hope acid-state 0.7 will be just as awesome ;)
02:46:46 <dsfgsdfg> then it might make sense to not include these in the main type, since if a propfind is issued to a handler that is not explicitly filtering...?
02:47:15 <dsfgsdfg> perhaps I'm over-thinking.
02:47:50 <donri> with OtherMethod they'd still pass through though
02:47:54 <dsfgsdfg> hmm
02:48:05 <donri> but it would be easier to filter them all out too
02:48:06 <stepcut> dsfgsdfg: not sure if that is really any worse than the current case where the same handler would support, PUT, DELETE, GET, TRACE, etc
02:48:14 <donri> CONNECT ;)
02:48:18 <donri> is that even implemented
02:49:01 <dsfgsdfg> k
02:49:12 <stepcut> donri: is there even an RFC for it?
02:49:27 <donri> no idea
02:50:51 <stepcut> not having to specify a method seems useful for things like 404 handlesr
02:50:54 <stepcut> handlers
02:51:08 <stepcut> but.. then there are also 405 handlers
02:52:39 <donri> bedtime
02:52:42 <stepcut> me too
02:52:49 <dsfgsdfg> well, thanks!
02:52:49 <donri> 5 am here
02:52:55 <stepcut> 10pm here :)
02:52:59 <donri> :)
02:53:50 <stepcut> we definitely need an OtherMethod Text constuctor, even if we also add webdav
02:53:58 <stepcut> so something like that is going in for sure
02:54:08 <dsfgsdfg> ok - good to know.
02:54:24 <dsfgsdfg> looks pretty solid from a quick glance otherwise.
02:54:36 <stepcut> but I am leaning towards also putting in the webdav constructors, because I don't see how that could hurt
02:55:17 <stepcut> I'll have to bump the hapsptack-server version to 7.1 though :-/
02:59:33 <dsfgsdfg> well, thanks again!
02:59:40 <dsfgsdfg> and good night
13:22:16 <Entroacceptor> wow, that new website looks enterprisy
13:22:21 <Entroacceptor> finally! :)
13:23:07 <donri> :)
13:23:15 <Entroacceptor> and congrats on the release
13:26:34 <Entroacceptor> but, there is a wiki that uses happstack, but the happstack wiki is hosted at google... :)
13:26:59 <donri> gitit is gpl :)
13:27:11 <donri> new website will have a custom built wiki soon
13:27:27 <Entroacceptor> you don't like the gpl?
13:27:37 <luite> hey guys, great new site! I was wondering if there's already some code available for the HTTP testing suite
13:27:55 <donri> luite: the grammar testing?
13:28:01 <luite> yeah
13:28:04 <donri> not that i know of
13:28:35 <donri> i think mainly stepcut read http://professor-fish.blogspot.se/2012/03/more-than-you-ever-wanted-to-know-about.html and got excited :)
13:29:19 <donri> Entroacceptor: i don't really know what i think. stepcut prefers BSD.
13:31:17 <Entroacceptor> on that: I can't find the license on that webpage
13:31:45 <donri> https://github.com/jgm/gitit/blob/master/LICENSE
13:31:59 <Entroacceptor> I'd expect to see it in "download" and probably "philosophy"
13:32:06 <donri> or do you mean the new happstack website?
13:32:10 <Entroacceptor> yeah
13:32:22 <Entroacceptor> so, take this as a website bug report
13:32:26 <donri> i think the code for the website isn't published yet, but will be open source
13:32:48 <Entroacceptor> no, I meant, I expect to see the Happstack license on the happstack website
13:33:04 <Entroacceptor> that I don't have to click through github to find it
13:33:10 <donri> ah, good point
13:33:33 <donri> it's listed as BSD3 on hackage
13:33:35 <Entroacceptor> it could even be on the main page
13:33:43 <donri> but might be worth putting that more frontal on the site
13:34:02 <luite> I didn't really like the Gitit GPL license for my own site, so in the end I decided to write my own wiki
13:34:10 <donri> i almost assume these days that web frameworks are BSD/MIT
13:34:12 <luite> which was lots of work and still not finished...
13:34:23 <donri> quite the shocker to realise the whole OPA *language* is *AGPL*
13:34:42 <Entroacceptor> haskell seems to love BSD/MIT
13:34:49 <Entroacceptor> but you can't just take it as given ;)
13:35:06 <donri> most GPL packages are from the same guy :P
13:35:15 <donri> gitit, pandoc, hscolour...
13:35:26 <Entroacceptor> and he writes great stuff :)
13:35:36 <donri> sure
13:35:47 <luite> yep it's a shame, because I need some markdown processing, and haskell highlighting
13:35:51 <luite> do everything in javascript now
13:35:56 <donri> luite: sundown, highlighter
13:36:53 <luite> donri: are there haskell bindings for that?
13:36:57 <donri> yes
13:36:59 <donri> @hackage sundown
13:36:59 <lambdabot> http://hackage.haskell.org/package/sundown
13:37:17 <luite> ah there are! cool
13:39:14 <luite> I'm a bit worried about inconsistencies with my client-side lib (markdown-js) though, but it would be nice to also have a way to view the pages without tons of javascript
13:47:38 <mightybyte> luite: How about pandoc?
13:47:49 <luite> mightybyte: gpl
13:47:58 <mightybyte> Oh, right.  Sorry, didn't read far enough back.
13:48:38 <mightybyte> Snap sidesteps that problem by only using the pandoc executable
13:51:13 <luite> btw, I wonder how acid-state gets 25000 updates (transactions?) per second on a laptop, it sounds impressive, but also a bit fishy, since the number of fsyncs per second that you can get out of a laptop hard drive is far lower. ideas?
13:52:19 <Lemmih> luite: You're doing them in parallel or you have an SSD.
13:52:20 <donri> luite: queued events are written in batch
13:52:52 <luite> Lemmih: yeah but the marketing material said that it was done on a hard drive
13:53:02 <Lemmih> Even with an SSD you should get an order of magnitude less requests per second, actually.
13:53:38 <donri> http://patch-tag.com/r/stepcut/acid-state-benchmarks/snapshot/current/content/pretty/counter/acid-state/Main.hs
13:53:40 <luite> donri: right, I suspected something like that, so all threads are blocked until a full batch has been written?
13:53:41 <donri> try it yourself :)
13:54:23 <donri> Lemmih will know better but i think events are queued up while others are being written?
13:54:53 <luite> yes I don't doubt the numbers, I'm just wondering if there's some tradeoff involved somehow
13:55:08 <donri> tradeof is fully in-memory DB :P
13:56:55 <Lemmih> luite: We can write X blocks to disk per second and we can fit Y transactions in each block. Transactions per second: X*Y.
13:57:18 <Lemmih> Latency: 1/X
13:58:32 <Lemmih> Compressing the transactions will increse the transactions per second. Using an SSD will increase transaction per second and reduce latency.
13:58:56 <luite> Lemmih: does it do some checkpointing or other method to ensure that incomplete blocks will not be read back?
13:59:12 <luite> if power fails while writing
14:00:07 <Lemmih> Right now AcidState just refuses to restore from an incomplete log. Then you'll have to unroll the damaged parts manually.
14:00:41 <Lemmih> You could write a tool for that but I haven't needed it yet.
14:00:53 <donri> but it does detect if the log is incomplete?
14:01:10 <Lemmih> Yes, with length and checksum.
14:06:12 <luite> hmm, lots of variation between runs, first run 42 seconds, second 7 seconds, third 24 seconds (deleted the state directory after the second)
14:08:17 <Lemmih> 4.255s, 4.224s, 4.212s. I love my new laptop.
14:09:31 <Lemmih> You can use scheduleUpdate instead of the forkIO thing if you only want to test AcidState and not the GHC RTS.
14:10:51 <luite> hehe mine is a bit slower probably, maybe it's OS X that does a bad job scheduling disk writes
14:11:32 <donri> luite: +RTS -N?
14:11:38 <donri> duno if that helps
14:11:47 <donri> did you try the sqlite one too for reference?
14:11:55 <luite> tried without first, with later, but the real time doesn't seem to change
14:12:26 <Lemmih> I get slower results with -N.
14:12:29 <luite> oh not yet, didn't know there was one
14:12:34 <donri> same repo
14:16:11 <luite> whoah the sqlite bench is so much faster ;)
14:17:06 <luite> testsq: failed to create OS thread: Cannot allocate memory
14:18:40 <Entroacceptor> haha
14:28:05 <stepcut> luite: are you on a desktop or laptop?
14:28:17 <luite> laptop
14:32:09 <stepcut> Entroacceptor: I added the license to this page, http://www.happstack.com/C/ViewPage/2
14:34:04 <Entroacceptor> now add it to http://www.happstack.com/C/ViewPage/1 and 5, too ;)
14:34:12 <stepcut> :)
14:34:18 <stepcut> later
14:34:23 <Entroacceptor> and change the urls, that's ugly
14:34:32 <stepcut> yeah, that is planned
14:34:38 <Entroacceptor> =)
14:34:44 <Entroacceptor> why the C?
14:34:47 <Entroacceptor> for language?
14:34:53 <stepcut> but didn't seem like a good enough reason to delay the launch
14:34:58 <Entroacceptor> yeah
14:35:44 <stepcut> things from the core module are prefixed with /c/
14:35:53 <stepcut> things from other plugins have different prefixes
14:36:14 <stepcut> so that they urls don't collide
14:39:53 <stepcut> s/they/the/
16:18:18 <stepkut> Lemmih: it seems like the acid-state backend APIs are setup such that you must always write new events/checkpoints to the place you restored from.
16:18:46 <stepkut> Lemmih:  for example, you can not use the Local backend to restore from some read-only medium but write to a different output directory
16:19:03 <stepkut> Lemmih: nor could you restore from the Local backend, but write to a Memory backend?
16:32:50 <user317> whats the best approach to handling IO with acid-state?  i need to run a transaction, but i want it to be atomic with respect to some IO action
16:33:32 <stepkut> ?
16:33:55 <user317> i want to do IO inside update
16:34:07 <stepkut> can't be done
16:34:11 <user317> and have the update fail if the IO operation fails
16:34:33 <user317> ok, thats what i thought, but you guys surprise me sometimes :)
16:34:41 <stepkut> you have to be able to replay events .. there is no way to ensure that replaying an event would result in the same answer if you could do IO in it
16:35:03 <user317> what about commiting a transaction and pending the success of some IO operation
16:35:18 <user317> so, it either throws an exception, or succeeds
16:36:27 <stepkut> why don't you do the IO operation, and then do the update?
16:36:47 <stepkut> rather, why can't you ..
16:37:37 <stepkut> there is not a general purpose solution for linking IO and update events.. but there are problem specific solutions
16:39:00 <user317> have you dealth with paypal ipn messages?
16:39:32 <stepkut> not yet.. need to soon
16:39:54 <user317> the protocol basically goes like this, you get a message, you send it back to get validated, you get the validation
16:40:39 <user317> so if i "commit" the transaction after i validate, it could fail, and i would loose the information that i have that payment sitll pending
16:40:57 <user317> but i need it validated before i commit it
16:41:03 <stepkut> ugh. I have to run, but I would be happy to present a solution to this later.
16:41:24 <user317> ttyl
16:41:27 <stepkut> you basically need to assume that the server could be kill -9 at any point in time and how to recover from that
16:41:35 <user317> yea, i know
16:41:52 <user317> it would be nice if i could tie the validation IO with some acid state transition
16:42:05 <stepkut> even if we could do IO inside a transaction, you could have the situation where the IO completed, but the server was killed before the update event was finished writing
16:42:23 <user317> i guess, recieve message, commit "pending" to the db, send validation, change pending to validated
16:43:01 <user317> so if i get killed after i am validated, i am still aware that its pending and i can have paypal resend it
16:43:03 <stepkut> yeah.. it depends on your ability to resend a the validation
16:43:19 <user317> ugh, yea, that ugly enough it might work :)
16:43:38 <stepkut> I don't think you can really do much better than that with any system ?
16:43:45 <stepkut> really gotta run, bbl.
16:43:48 <user317> later
16:45:13 <donri> user317: have a validated :: Bool field in your record and update it later?
16:47:06 <donri> then you can easily list all unvalidated records at say, start up, and retry them
16:52:14 <donri> or a data Valid = Valid | Invalid | PendingValidation, perhaps
16:55:48 <donri> Validity might be a better type name :)
17:00:42 <user317> yea, thats what i am thinking
17:22:07 <LambdaDusk> Good day, starting out on happstack... is there some sort of auth implementation?
17:23:02 <donri> LambdaDusk: do you mean authentication or authorization? do you need a custom login system or is third-party logins ok?
17:23:50 <LambdaDusk> donri: I would like a bunch of third-party logins, like twitter, facebook, google-oauth etc
17:24:29 <donri> use the authenticate package
17:33:38 <LambdaDusk> and with happstack, I have to take care of sessions myself?
17:35:21 <donri> you could use the clientsession package, shouldn't be difficult to integrate
17:35:34 <donri> or you could store session data in acid-state and some identifier in a cookie
17:35:53 <LambdaDusk> donri: Yes, I though so...
17:36:02 <donri> reusable components for things like authentication and sessions are on the roadmap
17:36:17 <donri> it currently involves some manual labor
17:45:09 <LambdaDusk> donri: Thanks for the tips.
18:30:43 <donri> stepcut: new haskell-src-meta meaning we can use jmacro without $
18:31:20 <donri> i shouldn't be this happy about that but it's so much less fugly :D
18:31:24 <luite> won't work in 6.x though :)
18:31:34 <donri> ghc?
18:31:39 <luite> uh yes, sorry
18:32:30 <luite> dunno if you still support that
18:32:39 <luite> yesod has dropped support recently
18:32:52 <luite> and most of the $ quasiquoters have been replaced
18:33:20 <donri> all i know is that support for 7.4 has been added :P
18:34:10 <donri> now i just need to rebuild ghc-mod so vim doesn't complain about the quasis either
18:35:29 <donri> ah you mean the quasis themselves in ghc. i thought you meant language-src-exts/meta
18:37:47 <luite> oh, yes
18:41:51 <stepcut> donri: epic!
18:45:08 <donri> stepcut: worth adding to happstack-server? neverExpires = setHeaderM "Expires" "Mon, 31 Dec 2035 12:00:00 GMT" -- this is supposedly the highest value you can set for ie6 ^_^
18:46:44 <stepcut> donri: ie6 eh ?
18:46:57 <donri> yea, well, other browsers are like 2038 so not a lot of difference
18:47:01 <stepcut> ah
18:47:22 <stepcut> seems reasonable
18:53:16 <luite> I try to support IE6 as little as possible ;p
19:00:22 <donri> stepcut: http://darcsden.com/dag/happstack/patch/20120330185916-6eb02 good?
19:01:00 <LambdaDusk> Is it normal that :reload-ing the source in ghci does not change the produced site at all?
19:01:51 <donri> did you restart the server?
19:02:34 <LambdaDusk> of course
19:02:46 <LambdaDusk> stopped the server with ctrl+c
19:02:50 <LambdaDusk> then did :r
19:02:58 <LambdaDusk> then called the "main" function
19:03:06 <LambdaDusk> but the result html is the same
19:03:33 <LambdaDusk> i have to explicitely quit ghci and restart it entirely, then it works
19:03:37 <donri> what template solution?
19:04:07 <LambdaDusk> direct in Blaze
19:04:28 <donri> how are you using ghci, cabal-dev?
19:05:45 <donri> "cabal-dev ghci" will know better about your modules than plain ghci
19:06:07 <LambdaDusk> oh?
19:06:24 <LambdaDusk> i didn't know cabal-dev and ghci can co-operate
19:06:33 <LambdaDusk> but I only have one file, called Main.hs
19:06:48 <LambdaDusk> for testing & learning
19:07:58 <donri> i don't see why that wouldn't work, but cabal-dev ghci really does work here (with hsp, but blaze should be no different)
19:08:19 <donri> also i'm using :main
19:08:26 <donri> which shouldn't matter either but hey :)
19:09:11 <LambdaDusk> hm
19:09:21 <LambdaDusk> so there's no caching in between or something?
19:09:57 <donri> not if ghci claims :r recompiled Main
19:10:31 <LambdaDusk> incidentally, is there a fnction in happstack-lite that will give me the entire post-query string unparsed?
19:11:12 <donri> lite is... lite, so you can skim http://hackage.haskell.org/packages/archive/happstack-lite/7.0.0/doc/html/Happstack-Lite.html :)
19:11:18 <stepcut> LambdaDusk: do you want the QUERY_STRING parameter from the URL or the body from the Request ?
19:12:08 <LambdaDusk> stepcut: From the body... There are trouble with a foreign POST request and I want to know exactly what data they are sending me
19:12:23 <LambdaDusk> I just love it when API changes without any documentation
19:13:09 <stepcut> LambdaDusk: you might need to import takeRequestBody from Happstack.Server for that functionality
19:13:14 <donri> you can import askRq from happstack proper and print the request, it's all nicely formatted
19:13:38 <stepcut> donri: but that will not include the Request body
19:13:52 <donri> ah
19:14:27 <stepcut> the only trouble is that you can't use takeRequestBody if the body as already been decoded by decodeBody (which is called implicitly in happstack-lite)
19:14:56 <LambdaDusk> hrm
19:15:01 <stepcut> though only when the request content type is multipart/form-data
19:15:12 <LambdaDusk> ah wait I can do it via JS
19:15:15 <stepcut> :)
19:15:37 <donri> some people, when confronted with a problem, think "I know, I'll use JS!"
19:15:45 <stepcut> it should not be that hard to switch to simpleHTTP from Happstack.Server if the javascript route does not work
19:16:23 <LambdaDusk> I just started with lite and it is so very convenient with dir and such
19:16:41 <donri> those are just exports from happstack-server
19:16:53 <stepcut> mostly.. you just call simpleHTTP instead of the serve function instead of serve
19:17:09 <donri> and nullConf instead of Nothing
19:17:16 <LambdaDusk> oh
19:17:57 <stepcut> LambdaDusk: right. happstack-lite is basically just a useful subset of the full happstack-server. So, when you start to run into limitations, you can easily import additional things from happstack-server
19:18:17 <stepcut> the only new function that happstack-lite defines is the 'serve' function I believe
19:18:25 <LambdaDusk> stepcut: Oh! I thought it was like, easier and simpler
19:18:47 <donri> ...which in turn is basically just a wrapper for simpleHTTP + decodeBody, more or less
19:19:46 <donri> LambdaDusk: well it sort of is, because you get the single module with just the basics
19:20:28 <donri> but it's using the same code under the hood
19:21:42 <LambdaDusk> ok thanks
19:22:02 <stepcut> LambdaDusk: it is easier and simpler because there are less distractions. And the type signatures have been simplified. But in a manner that keeps it full compatible with happstack-server so that you can import new functionality as you discover you need it
19:22:02 <donri> stepcut: http://www.facebook.com/happstack 404
19:22:08 <donri> linked from community page
19:22:17 <stepcut> works for me..
19:22:31 <donri> huh, force reload did it
19:22:51 <stepcut> "On March 30, 2012, all Facebook Pages will get a new design. Preview your page now to see what it looks like and try out the new features."
19:22:54 <stepcut> that's today!
19:23:05 <stepcut> gotta make sushi, bbiab.
19:25:35 <LambdaDusk> so "ServerPart Response" is not the type used by happstack-server?
19:26:05 <donri> it has that same type synonym
19:27:13 <LambdaDusk> oh ok
19:27:26 <LambdaDusk> and can be liftIO'ed
19:29:32 <donri> yep
19:30:42 <donri> the types are compatible between -lite and -server, and tend to be more specific in -lite and more general in -server
19:31:01 <donri> method :: (ServerMonad m, MonadPlus m, MatchMethod method) => method -> m ()  -- happstack-server
19:31:17 <donri> you can use that in a ServerPart, but also any other monad that implements those necessary classes
19:31:36 <donri> method :: MatchMethod method => method -> ServerPart ()  -- happstack-lite
19:31:43 <donri> that one you can only use in a ServerPart
19:33:23 <donri> it's similar to `Num a => a` vs e.g. `Int`
19:38:06 <LambdaDusk> and how do I activate some logger for the -lite app? I have an internal server error and don't know why
19:39:21 <donri> https://github.com/dag/happaste/blob/master/src/Main.hs#L36
19:39:43 <donri> import System.Log.Logger
19:40:58 <LambdaDusk> oh man thanks
19:41:05 <LambdaDusk> I like this somehow better than Yesod
19:41:30 <donri> :)
19:45:21 <LambdaDusk> now to find out how to send an https request from my server to another
20:40:44 <LambdaDusk> I want to like the Text and ByteString types, but I can't
20:45:06 <donri> :)
20:45:12 <donri> any particular reason?
20:46:01 <alpounet> LambdaDusk, are you using {-# LANGUAGE OverloadedStrings #-} ?
20:46:11 <alpounet> i hope so!
20:46:20 <alpounet> if you're not, then i understand
20:46:20 <LambdaDusk> alpounet: That is not the problen
20:46:28 <LambdaDusk> because I do
20:46:28 <alpounet> what is, then?
20:46:46 <LambdaDusk> the problem is: There are two types that are called "Text" in the docs
20:46:52 <LambdaDusk> it just says "text"
20:47:12 <LambdaDusk> but there's Lazy and Strict text types
20:47:16 <donri> if you follow the link or hover to see it in the statusbar, you'll see if it's lazy or not
20:47:24 <LambdaDusk> well yeah
20:47:34 <donri> but yes that can be confusing :)
20:47:45 <LambdaDusk> and then you need to convert them into one another ^^
20:47:52 <LambdaDusk> ByteString is even worse
20:48:01 <donri> they serve different purposes
20:48:09 <LambdaDusk> there's Word8 and Char8, each strict and lazy
20:48:16 <LambdaDusk> but it just says "ByteString"
20:48:27 <alpounet> i've never used the Word8 version I think
20:48:40 <LambdaDusk> that would surprise me
20:48:49 <LambdaDusk> It's way more common
20:48:56 <donri> i think Char8 is the same type, just a convenient api
20:49:47 <LambdaDusk> wow I made a browserId login and it just took me two hours!
20:50:11 <donri> :)
20:50:45 <LambdaDusk> what I dislike about Text/ByteString actually is all the conversions you need to make from one type to another - It always feels like sacrificing speed for the type checker
20:51:06 <donri> the point of those types is added performance
20:51:52 <LambdaDusk> so they say <.< >.>
20:51:57 <donri> :)
20:52:10 <LambdaDusk> surely not development performance
20:52:14 <LambdaDusk> ah I love haskell
20:52:18 <LambdaDusk> in it's beauty
20:52:27 <luite> if you have to convert between Text and ByteString, you'd probably have to convert if you worked with lists as well
20:52:28 <LambdaDusk> this sheer, wonderful beauty
20:52:33 <luite> [Char] vs [Word8]
20:53:30 <LambdaDusk> and yet... yet I often cheat on Haskell with the not as beautify, but easier JavaScript
20:53:43 <LambdaDusk> ok, she's ugly, but very easy to get in bed
20:53:46 <luite> Char8 ByteStrings are slightly evil
20:54:19 <luite> btw Char8 and Word8 ByteStrings are the same
20:54:24 <luite> no difference in type
20:54:30 <LambdaDusk> yes
20:54:46 <LambdaDusk> why does the typechecker complain about them, then?
20:55:24 <donri> it shouldn't
20:55:24 <luite> there still is a difference in types of the functions that operate on them
20:56:31 <donri> LambdaDusk: got an example it complains for?
20:57:53 <LambdaDusk> donri, luite: Ok, sorry, I was wrong
20:58:02 <donri> it happens :)
20:58:34 <donri> it *is* confusing because the Char8 modules re-export the type but it's not listed as such in haddock
20:58:35 <luite> np, I was confused first as well when I saw them, since it's not immediately clear from the haddocks
20:58:41 <donri> :)
20:59:11 <LambdaDusk> yeah
20:59:38 <LambdaDusk> wait a moment then I can drop my "map (toEnum . fromEnum)" stuff!
21:03:47 <donri> conversion might not be as expensive as you think, since text is actually a bytestring under the hood and lazy is just chunks of bytestrings/texts
21:04:32 <donri> and it might be less expensive than running computations on an unfitting type
21:05:01 <LambdaDusk> I've heard that GHC will optimise away many common conversions anyway
21:05:21 <LambdaDusk> like liftIO
21:06:35 <donri> do you understand the point of each of the four types?
21:07:44 <LambdaDusk> yeah, more or less
21:08:22 <LambdaDusk> they're actually just arrays, but as such more efficient than the list-based String type
21:08:45 <donri> yes but do you get the difference between the four and their individual benefits/purposes?
21:09:07 <LambdaDusk> the Lazy ones are for chunked reading/writing, so not the entire string has to be held in RAM if not necessary
21:09:25 <donri> yep
21:09:40 <LambdaDusk> and Word8 is the binary type, the Char8 ones are for easier work with the normal String-based function
21:10:16 <donri> and bytestrings are for data that is either binary, or has a known/fixed encoding and we don't need to work with it as text-as-such
21:10:52 <donri> text is decoded unicode text, doing the right thing for things like "length" (number of "characters" rather than "bytes")
21:11:11 <LambdaDusk> ByteString can also be used for non-unicode text
21:11:19 <donri> so text adds some overhead, but avoids some problems when what you're dealing with is actual text
21:11:35 <donri> yep, = binary
21:12:07 <donri> so yea, it'd be nice if we could just have one type and everything just worked and also there was ponies and rainbows
21:12:35 <donri> but even then, [Char] is probably *not* the optimal type for it
21:12:54 <donri> (just look at how Show is implemented for strings)
21:13:17 <LambdaDusk> read is worse ^^
21:13:39 <donri> quite likely
21:19:17 <LambdaDusk> at least Haskell doesn't suffer a common problem in languages: Equal Operators with different Meanings
21:22:47 <LambdaDusk> anyway, thanks for the help, I am off to bed
21:35:33 <donri> someone should make an xmpp server or client using hsx
21:36:02 <donri> just for the lols
21:36:05 <stepkut> :-/
21:36:14 <donri> :D
21:51:18 <alpounet> damn it, i haven't found 1 single hour i could spend on scoutess
21:51:19 <alpounet> damn it
21:51:28 <alpounet> this week was insane
22:00:48 <donri> stepkut: did you see my patch?
22:38:21 <etarasov> congratulations on the release! you guys make a really awesome thing!
23:16:42 <luite> k done, I think it's better now, will commit after a bit more testing, just in time for 1.0 :)
23:16:55 <luite> uh wait that was for #yesod
23:23:58 <donri> luite: dude we're at 7.0 ;)
23:24:51 <luite> yeah yesod is way behind :(
23:25:12 <luite> also in website design quality...
23:26:06 <donri> not that we ever had a 1.0 :)
23:26:10 <donri> 0.5 -> 6.0
23:26:17 <luite> oh hehe didn't know that
23:26:37 <luite> why not just 1.0?
23:27:26 <donri> well it's actually -> 6.0.0 etc, so just dropping the zero
23:29:31 <donri> i.e. you could say 0.5 is "happstack 5"
23:31:08 <luite> "yesod 11, now with conduits 4!"
23:31:16 <donri> \o/
23:31:22 <donri> "chrome 17"
23:31:27 <donri> or is that "old" now?
23:31:27 <luite> yeah like that :)
23:31:36 <luite> I think 18 was released, not sure
23:31:53 <luite> yeah I have 18
23:32:04 <donri> ---> Package google-chrome-stable.i386 0:18.0.1025.142-129054 will be an update
23:32:07 <stepcut> donri: yes, looks good. Remind me to pull it tomorrow. Going to a birthday party now
23:32:08 <donri> quite!
23:32:14 <donri> stepcut: have fun!
23:32:36 <stepcut> I got the dropping the zero trick from emacs
23:32:50 <donri> it's good marketing ;)
23:32:51 <stepcut> the were at 1.x for a long time, and then they just dropped the 1
23:33:10 <stepcut> it was good marketing, but also driven by the package version policy
23:33:32 <stepcut> for a version like, a.b.c, you have to bump 'b' anytime you change the API
23:33:44 <donri> at some point you realize you're way too conservative about major version bumps
23:34:02 <stepcut> and so it was annoying to talk about the 0.8 release (for example) and the suddenly have to make a 0.8 release for something else, and now all the 0.8 is really 0.9 stuff
23:34:12 <donri> stepcut: hm i think the two first are the "major version" in PVP
23:34:27 <stepcut> so, it was easier to make the 'a' represent a set of goals, and then we can bump 'b' all we want
23:35:20 <donri> i don't think the pvp says anything about the "b"
23:36:32 <stepcut> well. it says that if you change the API then the new A.B must be higher than the old A.B
23:36:57 <donri> ah yea
23:37:01 <stepcut> so, we decide to make 'A' represent a set of goals, and use the 'B' part to comply with the policy
23:37:27 <stepcut> with 0.B, we could not keep the two separate.
23:37:29 <donri> yea, you could have just added a D but this is less verbose
23:37:47 <stepcut> I don't see how a D would help
23:37:57 <donri> oh yea you're right
23:38:08 <stepcut> it's the A.B part that *must* be bumped when you break the API
23:38:27 <donri> yea i was confused, nevermind :)
23:39:29 <stepcut> when I add the new constructors to data Method, that will require a bump in A.B. I am glad I can just release happstack-server-7.1.0, and not have to upgrade all the references on the website about happstack 8 :p
23:39:38 <donri> i was reading it backwards, or something... :P
23:39:45 <stepcut> ah
23:40:03 <donri> a.a.b.c :P
23:42:20 <stepcut> gotta ways to go before we catch up with HTTP though
23:42:28 <stepcut> 4000.b.c or something like that :p
23:45:49 <donri> but it skips 1000 for each major yea