02:51:21 <stepkut> donri: so.. I have been looking at this ToJExpr instance..
03:59:37 <stepkut> donri: do a darcs pull. I added some more experiments to hsx-jmacro
04:01:09 <stepkut> such as the JMacroT monad which has an XMLGenerator instance. It does not use the XML type at all. It directly generates the javascript DOM functions to build the html on the client side.
04:04:44 <donri> stepkut: cool, but i think the innerHTML way is both faster and less bytes to send?
04:05:20 <stepkut> in terms of speed, it depends on the browser:
04:05:22 <stepkut> http://jsperf.com/dom-vs-innerhtml/10
04:05:26 <stepkut> they are both pretty close
04:05:43 <stepkut> (higher is better in that graph)
04:07:12 <stepkut> if you are using xhtml.. then innerHTML is not an option.. but who actually uses xhtml ?
04:07:40 <donri> are you sure?
04:07:50 <stepkut> that you can not use innerHTML with xhtml?
04:07:52 <donri> yea
04:08:09 <donri> or do you mean, you have to generate xhtml for the inner"HTML" then
04:08:22 <stepkut> no.. it used to be true
04:08:26 <stepkut> no idea what the current state of things is
04:09:29 <donri> aye :)
04:10:13 <donri> nice to have both options
04:10:20 <stepkut> yeah
04:10:28 <stepkut> especially since I can't really tell which is best/right
04:10:42 <stepkut> though we do need to pick a default for ToJExpr XML
04:10:52 <stepkut> but, if you don't like the default, there is a way to override it
04:11:08 <stepkut> though.. converting from XML -> JExpr has a problem that you sometimes need innerHTML anyway
04:11:11 <donri> why, is there more than one possible instance for XML?
04:11:34 <stepkut> because there is more than one way to convert from XML -> JExpr (innerHTML vs DOM)
04:11:46 <donri> but you said DOM way doesn't use XML
04:11:57 <stepkut> no. that is different
04:12:26 <stepkut> there are two ways to convert from the XML type to JExpr. But you can also use the XMLGenerator JMacroT instance and skip the XML type entirely
04:13:05 <donri> there is also the option to generate just the string, which is the least bytes and let's you write the innerHTML yourself or just pass it to jquery/yui etc... but i don't like the lack of type safety in that one
04:13:26 <stepkut> yeah
04:14:09 <donri> not that javascript is strongly typed, but let's not make it worse eh
04:14:13 <stepkut> :)
04:14:41 <stepkut> so.. we have 3 methods now. Not sure how to best evaluate them. But for now, ToJExpr XML still works the way it did before
04:14:46 <stepkut> there are just additional options available
04:15:19 <donri> cool
04:15:19 <stepkut> I was thinking of making a blog post, which will help clarify my thoughts, and give a chance for other people to comment
04:15:30 <donri> another reason i wrote it like i did is it was simply so easy
04:15:34 <stepkut> :)
04:15:46 <stepkut> there are lots of things that are easy.. I want best!
04:15:52 <donri> exactly
04:15:59 <stepkut> but.. I have no idea what best really is here
04:18:06 <donri> i'd argue that people shouldn't use xhtml, that innerHTML seems to be faster in all engines except webkit and that probably bytes over the wire is a bigger bottleneck than browser rendering...
04:18:34 <donri> but i'd also argue it's not *really* happstack's place to say "can't use xhtml", and webkit is still perhaps the second most used engine...
04:18:39 <donri> i'm not helping, am i
04:19:57 <stepkut> :)
04:20:10 <donri> it would be possible to minimize the total bytes in the DOM version with like, var !c = document.createElement; c('div')...
04:20:34 <stepkut> sure?
04:21:57 <stepkut> I think the JMacroT instance is neat because it shows how HSX is abstracted from any particular XML type.. but whether that is any benefit in using it is far less clear
04:23:00 <donri> it's certainly has cuteness to it that it renders as function calls client-side...
04:23:13 <stepkut> yeah
04:23:36 <stepkut> there was a lot of hate for innerHTML pre-2005.. but maybe that is not true anymore
04:23:42 <donri> there's a 4th option! javascript has something similar to hsx :D
04:23:51 <donri> but only firefox supports it :D
04:23:55 <stepkut> :p
04:23:56 <donri> let's use *that*
04:24:03 <stepkut> :-/
04:24:37 <stepkut> well, I'll fix the one issue i know about with XMLToDOM, and then we can release it I guess :)
04:25:00 <stepkut> and I need to comment JMacroT better
04:25:39 <stepkut> and it probably needs a few additional instances
04:27:16 <stepcut> also JMacroT may not be the best name
04:27:32 <stepcut> or maybe JMacroT should be an instance of IntegerSupply
04:33:19 <stepcut> might be interesting to create an XMLGenerator instance that generated blaze-html
04:36:45 <donri> or wl-pprint-text to minimize the duplication in your Builder code? but i guess it'd be slower probably
04:37:51 <stepcut> how would that minimize duplication?
04:38:00 <donri> if for some reason you really do want pretty rendering, it would probably make it easier because it knows how to wrap and indent lines within a margin width
04:38:01 <stepcut> I really don't know what wl-pprint-text does
04:38:20 <stepcut> ah
04:38:23 <donri> well you'd get a compact and pretty rendering from the same code
04:39:04 <stepcut> I tried to convert the XML type to blaze-html once.. and that was slower than the current String based code :-/
04:39:13 <donri> heh
04:39:19 <stepcut> but an XMLGenerator instance that directly creates blaze-html might be faster
04:58:23 <stepcut> the problem with blaze-html is that we have a string like "div" .. but I don't see a simple way to convert that into a div tag
04:58:39 <stepcut> without a big case like, case str of "div" -> Blaze.div
05:09:01 <stepcut> looks like hamlet just turns, <p>hello into, Blaze.preEscapedText . Text.pack $ "<p>hello</p>"
05:13:04 <stepcut> so.. we could just use the current renderer and wrap it in one big, preEscapedText :p
05:23:33 <donri> stepkut: a = Parent "a" "<a" "</a>"
05:23:36 <donri> does that not help?
05:25:05 <stepkut> donri: we would need a function like, parent str = Parent (fromString str) (fromString $ '<' : str) (fromString $ "</" ++ str ++ ">")
05:25:11 <stepkut> not sure that is really going to make things better
05:25:52 <donri> yea
05:26:40 <stepkut> seems like blaze-html is kind of a write-only format?
05:27:25 <stepkut> like.. there aren't really any tools to deconstruct a blaze Html document
05:27:57 <stepkut> so.. generating the html however we want and wrapping a preEscapedText block around it is not all that bad of an idea
05:28:12 <stepkut> that is basically how I embed blaze-html inside HSX :p
05:28:20 <stepkut> aka, (EmbedAsChild m Html)
05:31:53 <stepkut> of course, there are other options too :)
05:32:52 <stepkut> haskell-src-exts is what actually parses the literal XML syntax. And then trhsx is what converts that XML syntax into the XMLGenerator calls..
05:33:20 <stepkut> but we could have an alternative implementation that spits out valid  blaze-html instead
05:33:46 <stepkut> [blaze| <a href="foo">foo</a>]
05:34:14 <stepkut> would be converted to, a ! href "foo" $ "foo"
05:34:20 <stepkut> or whatever is valid blaze  syntax
05:38:11 <donri> what's the point though?
05:39:54 <stepkut> dunno
05:40:07 <stepkut> personally I do not like using the blaze combinators most of the time
05:41:07 <stepkut> implementing this is certainly not on the top of my list of things to do :)
05:42:10 <stepkut> but I think it is good to know what can be done.. in case it is relevant later
05:42:13 <donri> i think the combinators are the main interest point since they compose etc
05:42:43 <stepkut> yes
05:42:45 <donri> it's cute to have xml literals but i find most of the code ends up being <% %> stuff anyway
05:43:02 <stepkut> hm, not in my code
05:44:18 <donri> i like to refactor out patterns into functions
05:45:09 <donri> see from https://github.com/dag/happaste/blob/master/src/Happaste/Html.hs#L77 and down
05:45:14 <donri> mostly <%'s
05:46:29 <stepkut> i still find that more readable than blaze
05:47:07 <donri> true
05:48:34 <donri> i just often find i want to "surround this with some tag" and with combinators that would mean just prepending "tag . " to the inner container
05:48:50 <donri> and stuff like that
05:49:10 <donri> blaze makes it easier to DRY up attributes like !. for setting class, !# for setting id
05:53:17 <stepkut> if you comment out a few things hsx-xhtml builds :p
05:54:10 <donri> :)
05:56:46 <donri> so src-exts defines an XmlSyntax extension... would be cool to have an HtmlExtension that validates at parse-time
05:57:14 <stepkut> you could do that in trhsx
05:57:34 <stepkut> though, only the static parts obviously
05:57:40 <donri> of course
05:57:49 <stepkut> for the dynamic parts you have to use the runtime validation filter in happstack
05:58:00 <donri> but might be better to do it in src-exts so you don't need to run the preprocessor, it works with hlint etc
05:58:05 <donri> i.e. you get parse fail early
05:58:49 <donri> perhaps better linenos too?
05:58:52 <stepkut> dunno
05:59:02 <stepkut> maybe?
05:59:10 <stepkut> maybe the same
05:59:31 <donri> nibro only knows!
06:01:32 <stepkut> so, hsx-xhtml builds fine if you through in a few missing (XMLGenerator m) constraints
06:01:41 <stepkut> should be easy to port it to (x)html5
06:01:45 <donri> nice
06:02:43 <stepkut> but, I must go to bed now so I can get up tomorrow and release the things that are actually working already :)
06:02:54 <donri> \o/
06:02:55 <donri> good night
06:03:00 <stepkut> good morning!
06:03:05 <donri> in deed!
06:03:18 <donri> i actually slept this night, so we're out of sync again ;P
06:03:22 <stepkut> :p
06:03:30 <stepkut> I wondered where you were all day!
06:03:36 <donri> haha
06:16:49 <mekeor> @time
06:16:50 <lambdabot> Local time for mekeor is Fri Apr 20 08:18:04 2012
06:17:00 <mekeor> @time donri
06:17:02 <lambdabot> Local time for donri is Fri Apr 20 08:17:12 2012
06:17:08 <mekeor> @time stepkut
06:17:42 <mekeor> lol. look at the difference hehe
06:33:49 <donri> @time stepcut
06:33:50 <lambdabot> Local time for stepcut is Friday, April 20, 2012 1:34:00 AM Central Daylight Time
06:44:00 <mekeor> oh hehe :D thanks =)
16:15:02 <stepkut> my patches for fb have been pulled :p
16:15:20 <stepkut> yay me \o/
16:20:53 <HugoDaniel> pulled ?
16:21:32 <stepkut> pulled and released on hackage
16:21:47 <stepkut> I had to use git.. I feel dirty :p
16:22:41 <stepkut> the fb library provides facebook authentication (among other things) which is used by happstack-authenticate. But it was out-of-date (based on conduits 0.2)
16:22:46 <stepkut> so I submitted a patch
16:22:59 <stepkut> and then 2 days later Snoyman submitted a patch too :p
16:23:11 <stepkut> but, now it is actually merged and uploaded to hackage
16:32:40 <HugoDaniel> :)
16:32:46 <HugoDaniel> very good
22:00:07 <stepkut> I wonder what is a better name for the type used for the XMLGenerator instance for JMacro: JMacroT, DOMGenT, GenDOMT, something else..
23:28:36 <stepkut> oops.. scoutess would have caught that :-/
23:31:30 <Entroacceptor> minus the useless stuff?
23:31:41 <Entroacceptor> so happstack is bloat?
23:31:45 <stepkut> :)
23:31:51 <stepkut> some people think so
23:32:02 <Entroacceptor> but it doesn't do anything
23:32:19 <stepkut> ?
23:32:44 <Entroacceptor> compared to i.e. django
23:33:42 <stepkut> ah
23:34:39 <stepkut> the snap people will try to convince you that happstack is bloated
23:40:42 <Entroacceptor> I haven't heard much about snap lately
23:41:20 <stepkut> have you heard much about happstack lately?
23:42:00 <Entroacceptor> yes, there was a new release :)
23:42:06 <stepkut> :)
23:42:14 <stepkut> I am making a new minor release now (as you noticed)
23:42:17 <parcs`> wasn't snap created in light of happstack shortcomings? i wonder what those were
23:44:06 <stepkut> parcs`: snap was created because they wanted to create their own framework..
23:45:16 <parcs`> oh..