00:53:31 <donri> when I ^C an acidServer on a UnixSocket it doesn't clean up the socket
00:53:57 <donri> so the second run i get, bind: resource busy (Address already in use)
23:29:37 <donri> stepcut: aha. (did you mean to post here?)
23:30:03 <stepkut> donri: yes. You asked about whether Happstack 8 was going to use attoparsec vs hand-rolled bytestring parsesr
23:30:11 <donri> yea
23:30:18 <donri> and you replied in #haskell ;)
23:30:27 <stepkut> o
23:30:30 <stepkut> so I did
23:30:37 <stepkut> that's ok, they can know too
23:30:58 <stepkut> no use preaching to the choir
23:31:10 <donri> I thought the pipes parsing thing was about something else, like making it possible to hook things like attoparsec into a pipe
23:31:13 <donri> but i guess we'll see
23:31:18 <stepkut> yeah
23:31:33 <donri> there's also ekmett's new "parsers" library for type classes that he says could be used to write code independent of any one parser
23:31:39 <stepkut> when I tried to do parsers before there were issues with what happens to extra data in the pipeline
23:32:10 <stepkut> the ekmett's stuff could be useful for proving the parser correct
23:32:25 <donri> oh?
23:32:49 <stepkut> a type-class instance that returns a structure instead of actually parsing, and then you can somehow check that to make sure it matches the spec ?
23:32:52 <donri> i was thinking it could allow us to use parsec or trifecta in "development" for improved error reporting, and attoparsec in "production" for awesome speedz
23:32:58 <stepkut> right
23:33:02 <stepkut> I was thinking about that too
23:33:12 <stepkut> like... 5 minutes ago
23:33:16 <donri> although i'm not sure i see how that could work in practice, but i guess ekmett knows better than me ;p
23:33:24 <donri> @hackage parsers
23:33:24 <lambdabot> http://hackage.haskell.org/package/parsers
23:33:43 <stepkut> how it would be nice to have a 'debug' http backend that gave back sensible parser errors and attoparsec or something that is faster but gives crappy errors
23:33:57 <donri> yea
23:35:33 <donri> type classes / polymorphism is supposedly the enemy of performance, but maybe we could throw lots of SPECIALIZE on it
23:35:53 <donri> oh god this code is going to end up horrifying
23:35:59 <stepkut> better not!
23:36:20 <stepkut> if it is horrifying, then it is wrong :)
23:36:33 <donri> yea
23:38:13 <donri> anyway, personally i think i'd prefer a sane and reliable parser with attoparsec that is quite fast, over insane low-level bytestring raw operations that are crazy fast
23:38:28 <donri> but, possibly with grammar testing such insane code could be proven reliable anyway?
23:39:16 <donri> though maybe still easier to reason about a proper parser... and hack on it etc
23:44:22 <donri> so, acid-state. i'm having some weirdness with the remote backend
23:45:35 <donri> i have a program that connects to the remote server, but when it's done it never exits
23:45:55 <donri> the same program without connecting remotely exits fine
23:46:52 <donri> i'm using bracket with closeAcidState in both cases
23:47:35 <donri> also the remote server itself doesn't clean up its socket when aborted with ^C, so starting it again after that fails
23:49:55 <donri> aww