00:01:27 <ByronJohnson> Are there any plans to isolate the web server from web applications, as WAI's done?
00:09:30 <donri> yes
00:10:09 <donri> plan is to rewrite the webserver with pipes for happstack 8, and that'll likely come with a separation of server and API
00:10:21 <donri> but possibly via type classes rather than records
01:12:16 <donri> hm looks like wai uses Builder to allow concatenating all the pieces in as few syscalls as possible... wouldn't it be better to use lazy bytestrings and send each chunk as it is available with transfer-encoding:chunked?
01:13:44 <donri> stepkut: perhaps both could be supported!
01:17:50 <donri> or perhaps Builder supports that itself somehow
01:18:17 <donri> i'm sort of hoping for the built in builder in the bytestring package that never seems to be released though
01:22:59 <donri> http://people.inf.ethz.ch/meiersi/downloads/private/bytestring- \o/
01:38:49 <stepkut> donri: type classes seem unlikely to me.. I try to avoid them when possilbe
01:38:57 <stepkut> well... that is a bit strong
01:39:05 <stepkut> I try to avoid them when they don't have clearly defined laws
01:41:05 <donri> ok, i'm just (mis?)quoting you :)
01:42:16 <stepkut> dunno
01:42:27 <stepkut> maybe I am different now :)
01:42:48 <donri> tekmo having a bad influence on you eh?
01:42:50 <stepkut> but.. my caution towards type-classes is pretty long lived
01:43:08 <donri> happstack 8: mtl free? ;)
01:43:24 <stepkut> doubt that
01:43:42 <stepkut> but.. maybe it will use the Free monad :)
01:44:01 <donri> sounds interesting
01:46:03 <donri> oh hey http://hackage.haskell.org/packages/archive/blaze-builder/
01:46:26 <stepkut> :)
01:48:31 <donri> and http://people.inf.ethz.ch/meiersi/downloads/private/bytestring-
01:49:55 <donri> what i really want is for it to work together with hsx such that the html <head/> can be sent before the whole template is rendered
02:21:23 <donri> bedtime
07:58:13 <Lemmih> stepcut: acid-state-0.6.5 is now available.
07:58:20 <Lemmih> stepcut: Thanks for the patches.
17:50:56 <stepkut> donri: yeah, sending the <head> while generating the rest would be cool.. though that also puts a bunch of limitations on things
17:51:17 <stepkut> donri: sometimes I call escape while generating the <body> and return an entirely different page, for example
17:51:22 <stepkut> Lemmih: awesome!
17:53:31 <donri> perhaps like, we could have both behaviors, as different types, making escape a type error?
17:54:11 <stepkut> well, I can only use escape because I am using the ServerPart monad as the base for XMLGen
17:54:19 <stepkut> using Identity makes things a lot more straight-forward
17:54:54 <donri> although you may still want other things from serverpart?
17:55:10 <stepkut> for things like 'widgets', things in the body might add additional resources to a WriterT which need to go in the head
17:55:57 <donri> ah yea
17:57:19 <donri> i wonder if we could somehow evaluate those "tells" quickly but not the rest of the widgets
17:58:32 <stepkut> you would need to flatten the monad first. (runWriterT or whatever).. that would give you the extra stuff you need to add to the <head> and the XML
17:59:18 <stepkut> you could at that point add the extra stuff to the <head> and start sending the <head> before you have rendered the rest of the body XML to a ByteString
17:59:23 <stepkut> not sure how big of a win that is
18:00:01 <donri> the win is supposedly that browsers can start fetching assets as early as possible
18:00:19 <donri> and do more in parallel
18:01:03 <stepkut> right
18:01:34 <stepkut> but only if the time it takes to render the body is long enough that sending the head in advance makes a difference
18:01:44 <donri> sure
18:02:06 <donri> i'm just thinking it'd be a nice-to-have
18:02:53 <stepkut> at the level I just described, it might be extra complication that doesn't help because we supposedly generate the XML as a lazy bytestring, so while we do not send the <head> separately.. we may send out a chunk that contains the head plus a little extra?
18:02:59 <donri> i imagine it might matter if you have a large body, or you're doing something slow to generate the body
18:03:06 <stepkut> yeah
18:03:24 <stepkut> I think we need to first understand when sending the <head> would actually give it a good head start
18:03:59 <donri> i think lazy bytestring chunks are 64k big and builder chunks between 4k and 32k
18:04:23 <donri> so, if you have a not that big, but slow-to-generate body, the chunking might still keep it from getting sent early?
18:04:40 <donri> (but you can "flush" a builder to force a chunk, IIUC)
18:07:54 <donri> anyway shouldn't the template layer operate on Text (or a text builder) rather than bytestring?
18:09:25 <stepkut> bytestring is the very last stage
18:09:31 <stepkut> when you are going from the XML type to ByteString
18:11:33 <donri> sure
18:11:54 <donri> you'd think there'd be a T.Builder -> BS.Builder function somewhere
18:12:07 <donri> only find Text -> BS.Builder
18:14:56 <donri> man, performance is a bitch. you can have every single component in your chain super-optimized, except one that brings it all down
18:15:04 <donri> see also: security
18:16:03 <stepkut> :)
18:16:25 <donri> bbl dinner
18:17:17 <stepkut> later
20:22:39 <ByronJohnson> /This method defines how a value should be parsed without worrying about previous versions or migrations. This function cannot be used directly. One should use safeGet, instead./s/safeGet/safePut/ — http://hackage.haskell.org/packages/archive/safecopy/0.6.1/doc/html/Data-SafeCopy.html
20:24:19 <donri> in deed
20:24:34 <stepkut> ByronJohnson: is there a question?
20:24:59 <donri> maybe rephrase too, it's not really parsing?
20:25:07 <donri> stepkut: the haddock is wrong
20:25:19 <stepkut> ah
20:25:21 <donri> for putCopy
20:25:23 <stepkut> I see the s// now
20:26:00 <stepkut> Lemmih: ping
20:26:27 <ByronJohnson> < donri> maybe rephrase too, it's not really parsing? — Right; probably s/parse/serialize/ OSLT
20:36:56 <ByronJohnson> "| length cons > 255 -> fail $ "Can't derive SafeCopy instance for: " ++ show tyName ++ ". The datatype must have less than 256 constructors.""  — *Thank* you. =)
20:37:17 <stepkut> :)
21:15:58 <Igloo> "darcs send" thinks it should send patches to jeremy@n-heptane.com; is that right?
21:16:28 <Igloo> http://www.happstack.com/C/ViewPage/2 says patches should be sent to the mailing list, but I can't work out what the address for that is
21:17:08 <stepkut> Igloo: jeremy@n-heptane.com is fine
21:18:01 <Igloo> OK, ta
21:20:07 <Igloo> Would a patch to remove the need for -fno-warn-unused-do-bind be accepted, BTW?
21:20:54 <stepkut> yes
21:21:15 <Igloo> Cool. Is there a policy on what GHC versions happs supports?
21:21:26 <stepkut> as many as we can reasonably
21:21:32 <stepkut> but, we could make that narrower
21:22:17 <stepkut> At a minimum we want to support the current version and the previous version, and whatever is in the current haskell platform
21:22:39 <stepkut> we also support ARM :)
21:22:48 <Igloo> Well, the problem with a vague policy IME is that keeping things working for one extra GHC version is a small amount of work at any given time, but adds up to a lot of work in the long-run
21:23:03 <stepkut> right
21:23:26 <stepkut> the code is getting to the point where I would like to drop support for < 7.0 I think
21:24:18 <Igloo> That sounds like a good cut-off point to me
21:24:41 <stepkut> I am thinking that supporting the current GHC and the last two haskell platforms might be good ?
21:25:29 <Igloo> DYM last two HP major branches?
21:26:13 <stepkut> I have no idea
21:26:17 <Igloo> :-)
21:26:27 <stepkut> I am going to say yes?
21:26:45 <Igloo> ACTION is having trouble finding out what the previous HP release actually contained
21:26:48 <stepkut> the HP comes out twice a year ?
21:27:20 <stepkut> does supporting the last 'n' HP releases seems like a sensible policy for some number of 'n'
21:27:45 <Igloo> How about "as far back as the latest HP available 1 year ago"?
21:28:22 <Igloo> i.e. if you've installed the latest HP in the last year, then you can build happs
21:29:14 <stepkut> sure.. not sure if time based or number of releases is better.. they are, in theory, pretty closely linked
21:29:45 <Igloo> Not sure if you saw: i.e. if you've installed the latest HP in the last year, then you can build happs
21:30:52 <Igloo> My thinking is that if 3 HPs come out in a short period of time for some reason, then you don't want to drop support for relatively recent releases immediately. And conversely, if there isn't an HP release for a couple of years, then there's little benefit in supporting an even older release
21:31:43 <stepcut> makes sense
21:32:11 <stepcut> so, really the question is how much time back should we go. 12 months. 18 months, etc. For things like Debian.. a longer time might be useful ?
21:33:10 <Igloo> I don't have a strong opinion about the number; I just want to know what it is  :-)
21:42:43 <ByronJohnson> Is there a reason http://hackage.haskell.org/packages/archive/ixset/1.0.5/doc/html/Data-IxSet.html#t:Proxy was defined when http://hackage.haskell.org/packages/archive/tagged/ already exists?
21:46:49 <stepcut> ByronJohnson: ixset is is far older than that package
21:47:15 <stepcut> ByronJohnson: but, migrating to use tagged is a possibility
21:47:44 <stepcut> though Tagged and Proxy are a bit different
21:48:20 <ByronJohnson> Ah, 'k
21:48:20 <stepcut> data Tagged a b = Tagged b vs data Proxy a = Proxy
21:48:26 <ByronJohnson> (The tagged library provides both tagged and Proxy)
21:48:37 <stepcut> oh, opps
21:48:48 <stepcut> I was looking at the first release of Tagged :)
21:49:01 <ByronJohnson> Heh. =)
21:49:47 <stepcut> http://code.google.com/p/happstack/issues/detail?id=227
21:50:00 <ByronJohnson> Yeah, it' snot that important; I just like standardization and to be able to use those convenient functions that are based on the standard Proxy definition
21:50:04 <stepcut> I am all for using tagged.. just didn't exist last time I looked for it :)
21:50:22 <stepcut> right. I am 100% for a common Proxy type
21:50:39 <ByronJohnson> Thanks
22:06:05 <donri> i wish there was a hackage category "ekmett packages"
22:09:23 <ByronJohnson> Heheheh :D
22:09:29 <ByronJohnson> http://hackage.haskell.org/packages/archive/ixset/1.0.5/doc/html/src/Data-IxSet.html#ixSet — Minor typo in the documentation of ixSet: the list lacks commas
22:09:47 <ByronJohnson> no'i Or incoporate searching by uploader name
22:12:11 <ByronJohnson> (While we're at it, may as well clarify "Use ixFun and ixGen as list elements." with s/Use/& applications of/ OSLT)
22:21:25 <stepcut> donri: :)
23:00:12 <stepkut> which list lacks commas?
23:00:42 <stepkut> oh
23:00:43 <stepkut> I see
23:02:05 <stepkut> that whole haddock comment hurts my head
23:02:22 <stepkut> I'm pretty sure I didn't write it :)
23:15:11 <hpaste> stepcut pasted “ixset doc fixup” at http://hpaste.org/71741
23:15:16 <stepkut> any better?
23:16:46 <donri> yep
23:16:56 <stepkut> did I add any new typos?
23:17:09 <donri> i think we rephrased the last sentence recently, but i had someone ask in pm wtf that meant, even after our change
23:18:01 <stepkut> I'll expand it
23:18:42 <donri> don't see no typos
23:19:28 <donri> i ain't not see no typos no nowhere
23:19:42 <donri> (anyone watched the wire?)
23:27:55 <ByronJohnson> (There are also two other lists without commas towards the beginning)
23:29:54 <donri> obviously what we need to do is introduce a quasiquoter with a custom DSL for defining indexes