03:16:40 <stepcut> mm_freak: I just remembered that I have an alternative to dir/path and to snaps route function that is built around Category :p
09:54:17 <donri> mm_freak: care to blog about how you're using reflection with blaze-html? :)
09:59:26 <mm_freak> hi guys =)
09:59:41 <mm_freak> stepcut: what's the alternative?
09:59:49 <mm_freak> donri: once i get my now website running ;)
09:59:50 <mm_freak> new
10:00:12 <donri> mm_freak: the one using reflection? :D
10:00:57 <donri> stepcut might be talking about boomerang btw
10:19:40 <mm_freak> donri: stepcut knows that i'm aware of boomerang, so i doubt it =)
10:19:46 <mm_freak> i rather think this is for ad hoc routing
10:19:55 <mm_freak> anyway, no, my website won't be using reflection for i18n
10:20:13 <mm_freak> i'm currently implementing a website skeleton for happstack
10:21:55 <donri> i had some ideas for using darcs to do scaffolds
10:22:45 <donri> using darcs replace/move
10:23:03 <mm_freak> i'm doing ad hoc scaffolds using make
10:23:13 <mm_freak> i'm doing that for every haskell project i start
10:23:38 <mm_freak> if you want, i can create a tar.gz from my skeleton project…  it includes many things like testing and benchmarking
10:24:27 <donri> not that interested... i'm way too picky about how to structure such things ;)
10:25:05 <donri> well, might be interested to see if you have some interesting ideas in your skeletons
10:25:08 <mm_freak> me too, that's why i never liked scaffolding tools
10:25:43 <donri> hehe yea... that's partly why i'm considering a darcs-based system that makes it easy to make your own skeletons
10:26:05 <mm_freak> http://ertes.de/skel/
10:26:28 <mm_freak> my happstack skeleton isn't ready yet…  that's my generic haskell project skeleton
10:26:32 <mm_freak> see the Makefile in particular
10:26:54 <donri> yep
10:27:38 <mm_freak> and the skeleton.cabal file, if you want
10:27:43 <mm_freak> that's my project outline
13:11:23 <mm_freak> blaze-html with HTML5 produces "<!DOCTYPE HTML>" instead of the more common, XML-compatible "<!DOCTYPE html>"
13:11:27 <mm_freak> is this actually correct?
13:12:52 <donri> mm_freak: duno, but blaze's html5 combinators aren't xml compatible anyway
13:13:28 <donri> ugly anyway, report it!
13:14:44 <mm_freak> if it's correct, i don't really care…  it should produce the most compact valid output
13:14:56 <mm_freak> i've just asked in #html5
13:15:07 <donri> HTML isn't more compact than html
13:15:23 <mm_freak> but <br> is more compact than <br />
13:15:29 <mm_freak> or <br/> for that matter
13:15:39 <mm_freak> (i don't use <br> anyway)
13:16:26 <donri> yea, that's what i meant about not being xml compable regardless of the doctype
13:16:42 <mm_freak> yeah
13:16:52 <mm_freak> you know, i'm happy not to have to write HTML by hand =)
13:17:18 <mm_freak> HTML is so broken that i just don't want to
13:17:23 <donri> hehe
13:17:53 <donri> SGML and XML are both kinda nice, but HTML is a bastardization of the two, so to speak
13:19:33 <mm_freak> you really think, they are nice?
13:20:11 <mm_freak> SGML is really awkward…  XML is an improvement, but it's very noisy
13:20:26 <mm_freak> you know what's nice?  YAML and s-exps
13:20:45 <mm_freak> that's why i prefer to write blaze-html markup directly instead of using HSP
13:21:16 <donri> yaml kinda sucks for markup but sexp is nice yea
13:21:28 <mm_freak> why does it suck?
13:21:38 <donri> OTOH xml kinda sucks for data, where yaml is better :p
13:21:43 <mm_freak> it's haskell/cabal syntax for markup
13:21:58 <mm_freak> hamlet has about the same syntax
13:22:24 <mm_freak> hamlet templates are short and readable…  the corresponding HTML often fills pages with noise
13:22:42 <donri> not talking about syntax... markup is all about the inlines, neither json or yaml are good at that
13:22:53 <mm_freak> inlines like what?
13:23:28 <donri> <p><em>This</em> is an example.</p>  how do you write that in yaml?
13:23:54 <mm_freak> well, in hamlet you do about the same as in pure blaze-html
13:24:11 <mm_freak> i suppose in YAML you would do something similar
13:24:13 <donri> but yaml isn't hamlet
13:24:37 <mm_freak> YAML is just a framework…  your YAML could do hamlet-like things
13:24:59 <mm_freak> but that's best in haskell
13:25:18 <mm_freak> p (em "This" <> "is an example.")
13:25:19 <donri> you end up with something like, {p: [{em: This}, " is an example."]}
13:25:42 <donri> and then you try to add attributes to the mix and it gets even worse
13:25:51 <mm_freak> yeah, i get your point
13:26:04 <mm_freak> i guess the best markup language is haskell
13:28:22 <donri> i want a type safe version of blaze with a proper monad transformer
13:31:17 <mm_freak> you could build something like that on top of blaze-html
13:31:31 <mm_freak> btw, blaze (as in blaze-builder) is fine
13:31:41 <mm_freak> if you mean blaze-html, say it ;)
13:31:56 <donri> too long!
13:32:15 <donri> not sure what blaze-builder would give you in that case though
13:32:38 <donri> i'd also like rich types that you can manipulate
13:32:39 <mm_freak> "Last (Just 3)" is also too long, but if i say "3", then that's a type error
13:32:46 <donri> blaze is sort of write-only
13:32:58 <mm_freak> blaze-builder is just for fast string output
13:33:11 <mm_freak> it has nothing to do with HTML and is used by many other things
13:33:17 <donri> yea but it's also wrong because it's for bytestring
13:33:31 <donri> which also has its own builder these days
13:34:54 <mm_freak> you need to use one of those explicitly anyway
13:35:06 <donri> i'd use text :)
13:35:53 <mm_freak> that would be considerably slower
13:36:56 <donri> in my type safe css library i use [a patched] wl-pprint-text, and with the same code i can render pretty or minified
13:37:23 <donri> fast enough for me... duno if it's even a bottleneck
13:39:16 <donri> in my tests blaze-html only handled twice as many rq/s as [the old String based(!)] hsp
13:41:52 <donri> i'm not saying blaze-html isn't useful... but it's not my go-to choice for dynamic web apps
13:42:15 <donri> it'd be great for things like rendering in a syntax highlighter
13:42:30 <donri> rendering parsed markdown...
13:42:37 <mm_freak> for CSS you have the advantage that they are usually not dynamic
13:43:08 <mm_freak> why wouldn't blaze-html be useful?
13:43:25 <donri> well i'm making my lib a monad transformer (as an option, on top of a monoid interface) so you could use web-routes for image assets etc
13:43:46 <donri> i duno, i just said it is useful?
13:46:05 <mm_freak> you said: "but it's not my go-to choice for dynamic web apps"
13:46:07 <mm_freak> and i wonder why not
13:49:45 <donri> but we've been over that? web-routes, i18n... and even with reflection, you still have to call toHtml everywhere, and you can't do IO in templates (i know it sounds bad, but i like doing acid-state queries in templates... with hsp i can just write <p><% Counter %></p> and it runs the Counter query)
13:50:13 <donri> and it's optimized for utf-8... normally ok, but considerably slower than text if need another encoding
13:50:51 <mm_freak> i'm taking a monoidal approach for everything, including templates
13:51:13 <mm_freak> templates without side effects make this well defined
13:51:27 <donri> sure, i do see the benefits of that too
13:52:18 <mm_freak> i'm happy to extract the URL renderer using askRouteT and have templates as regular functions
13:52:26 <mm_freak> what's a template that depends on data from the database?
13:52:30 <mm_freak> it's a function of that data
13:52:36 <mm_freak> the concept makes sense and is composable
13:52:50 <mm_freak> what's a template interleaved with IO actions?  it's an IO action itself
13:52:58 <mm_freak> it's not a template, not a function and it's not composable
13:54:26 <donri> sure. gets a bit unwieldy though when you have a lot of those queries and you have to run them in the web handler and pass them around as arguments everywhere
13:54:29 <mm_freak> worse yet, it has template output as a side effect
13:54:43 <mm_freak> you have a functional language with higher order functions =)
13:54:56 <mm_freak> it doesn't get unwieldy
13:56:02 <mm_freak> you should probably try it =)
13:56:23 <donri> i did. admittedly when i was a haskell beginner
15:58:17 <LambdaDusk> does happstack have support for streaming responses?
16:01:02 <mm_freak> LambdaDusk: only if they are pure in the form of lazy bytestrings
16:01:09 <mm_freak> you can use websockets, though
16:01:12 <donri> LambdaDusk: depends what you mean
16:01:27 <LambdaDusk> mm_freak: Websockets are an instable overkill for my purpose, I need EventSource
16:01:53 <mm_freak> you can push stuff, if that's what you want
16:02:07 <LambdaDusk> do you have some code examples on that?
16:03:02 <mm_freak> do you need code examples to wait for some STM action?
16:03:29 <mm_freak> push essentially just means:  the client connects and the server responds, as soon as a response is available
16:05:05 <LambdaDusk> well, the eventsource is more like a long polling
16:05:14 <LambdaDusk> I thought of a TChan there
16:05:38 <LambdaDusk> I just need to know if it's reliably possible to append stuff to a happstack response
16:08:16 <mm_freak> a response is basically just a lazy bytestring
16:11:00 <mm_freak> that's fine as long as you don't want to stream a large file…  you would want to use sendfile there
16:11:42 <LambdaDusk> hm
16:26:11 <mm_freak> LambdaDusk: if you want to transfer multiple events through a single HTTP response, happstack might not give you what you need
16:26:28 <mm_freak> however, in that case you should really consider using websockets
16:27:01 <mm_freak> happstack works, as long as every event is transferred in its own response
16:27:01 <LambdaDusk> hm
16:27:45 <LambdaDusk> what is the status on the changes for happstack 8?
16:27:53 <mm_freak> the alternative is to add a small WAI/snap service on a different port
16:28:09 <mm_freak> happstack 8 is far from ready
16:28:34 <mm_freak> the necessary support libraries are being written, but there is no framework around them yet
16:33:09 <LambdaDusk> shan't there be a happstack-like lib on wai-basis?
17:13:22 <stepcut> LambdaDusk: I have experimented (in the pre-yesod days in fact) with ported happstack to wai.. it is certainly possible, but not especially compelling at this point
17:16:06 <LambdaDusk> well I would go on using Yesod but these highly complex type errors get on my nerves...
17:16:41 <LambdaDusk> not that happstack is any different when trying to include some html renderers...