00:05:54 <stepcut> donri: sure.. will it conflict with jQuery at all?
00:08:33 <donri> no
00:10:11 <donri> it enforces another _ anyway so we'll get like $_0 for normal renderings and $jkW42n_0 with hashed rendering and if we do it for hsx too we get $0_0 etc
00:10:37 <donri> jQuery only defines exactly $ as far as I know, which is also just an alias for "jQuery"
00:12:53 <donri> ACTION *cough* jquery breaks spec, yui doesn't *cough*
00:13:27 <donri> also, looks like jmacro sorta has a mini DSL already?
00:16:28 <donri> maybe it's for antiquotes because you can't nest quasi quotes
02:49:08 <donri> stepcut: heh, firefox has hsx ;) https://developer.mozilla.org/en/E4X_Tutorial/Introduction
08:40:24 <mekeor> mightybyte: you're on planet.haskell.org! :)
10:47:38 <Entroacceptor> I hope he knows ;)
16:40:38 <donri> stepkut: actually what yui does with Node.create(htmlString) is have the browser parse the string so it's both less bytes than manually building a DOM tree and faster than all those function calls
16:41:04 <donri> stepkut: so my yui code could easily be ported for jmacro to generic DOM I think
16:43:15 <donri> (basically (document.createElement('div').innerHTML = htmlString).childNodes[0], though i don't know if more things are necessary for cross-browser portability)
16:49:40 <donri> another reason for a jmacro monad; our hsp can be more than Identity for example RouteT
17:40:23 <donri> stepkut: re minification, here's some numbers http://yuiblog.com/blog/2006/03/06/minification-v-obfuscation/
17:40:38 <donri> minification reduces the compressed size by a third
17:44:15 <donri> by that definition hjsmin would seem to be a complete minifier, just not an "obfuscator". i haven't seen that distinction before though ...
17:47:06 <donri> on the other hand, jmacro already strips comments and onelinemode renders less spaces than typical raw source code; not sure if hjsmin adds much here
18:08:52 <Lemmih> Hm, meteor seems neat.
18:09:15 <Lemmih> Might make web dev pleasant enough for me to get back in the game.
18:11:43 <mekeor> Lemmih: my name is mekeor. did you mean me?
18:14:35 <Lemmih> Yes, I meant you.
18:15:14 <Lemmih> (You /are/ the guy who does my web development for me, aren't you?)
18:15:40 <donri> whatcha talkin bout
18:16:24 <mekeor> Lemmih: huh? am i? idk. i don't think so..
18:17:06 <donri> http://www.meteor.com/ ? except it's js, duuude
18:17:27 <mekeor> lol. that's not me.
18:17:41 <mekeor> i hate js.
18:17:58 <donri> wasn't it meteor that had forgotten about security like completely
18:18:34 <mekeor> WHO THE HELL IS METEOR???   *MY* name is mekeor.
18:18:52 <mekeor> donri: what do you mean?
18:19:06 <donri> meteor is a javascript web framework
18:19:29 <mekeor> mekeor is me. it's a recursive acronym. the "me" in "mekeor" stands for "mekeor" ;)
18:20:00 <donri> donri is the lojban word for the meaning of my swedish name. i can have geeky nicks too.
18:23:25 <Lemmih> I'd much rather deal with the ugliness of web-dev in js than in Haskell.
18:24:05 <Lemmih> And it's nearly functional, even. It's reactive.
18:27:54 <Entroacceptor> the meteor video doesn't talk about security at all
18:28:04 <Entroacceptor> but happily give direct db access to the clients
18:29:05 <mekeor> Lemmih: did i understand well? you prefer JS over HS ?
18:30:17 <Entroacceptor> and having lines like $ curl install.meteor.com | sh  in their examples make me sad
18:30:32 <Lemmih> Entroacceptor: That's fine. Don't want to use mongoDB in any case. AcidState is the way to go.
18:31:07 <Lemmih> mekeor: For templating, totally.
18:31:40 <luite_> hmm, I'm always a bit worried about scalability of javascript frameworks... not in requests per second but in number of bugs introduced per second when you change things in a larger site
18:32:32 <mekeor> Lemmih: oh... kay.
18:33:11 <Entroacceptor> you mean... the bugs are webscale?
18:33:39 <Lemmih> mekeor: Don't get me wrong. My love for Haskell still borders on the perverse.
18:34:15 <mekeor> Lemmih: :D
18:37:03 <luite_> yeah I understand the attraction to javascript, she just seems so much easier, so much fun, until afterward you've caught a nasty bug
20:57:09 <donri> Lemmih: what specifically hooked you on meteor?
21:10:05 <Lemmih> That it is reactive.
21:11:07 <Lemmih> donri: Several Haskell libraries have tried to do reactive web programming but doing it purely server-side is darn hard.
21:11:21 <donri> have you looked at "ji"
21:11:26 <Lemmih> Ji?
21:11:40 <luite_> that's by chrisdone, right?
21:11:53 <donri> http://chrisdone.com/posts/2011-12-26-ji-haskell-web.html
21:14:17 <Lemmih> Neat. Eventually one could do the same as meteor but in Haskell. Until then, meteor works fine.
21:15:41 <Lemmih> Oh, another nice thing about meteor is that you can delegate to non-Haskell people.
21:15:56 <stepcutextual> should happstack do something to support meteor?
21:16:12 <donri> Lemmih: http://xkcd.com/989/
21:17:11 <Lemmih> Having Haskell hackers write web clients is like having Nobel laureates teaching kindergarten.
21:18:12 <donri> stepkut: i ported the jmacro renderer to text
21:18:23 <stepcut> donri: nice
21:18:36 <Lemmih> stepcut: Nope, I don't think so.
21:18:36 <donri> using wl-pprint-text
21:19:03 <Lemmih> stepcut: I plan on creating a REST api with happstack and then using that from meteor.
21:19:05 <donri> the compact rendering is multiline :P
21:19:34 <stepcut> donri: I plan to be of sound state of mind again tomorrow.. so I can pull your happstack related macro patches.. is your Text patch a patch to jmacro itself?
21:19:49 <donri> to jmacro itself
21:19:54 <stepcut> donri: neat
21:20:07 <donri> http://darcsden.com/dag/jmacro but there's a darcsden bug in the changes log :(
21:20:23 <stepcut> donri: I would really like to see HSX ported to Text.. but HSX and OverloadedStrings do not get along well.. ambiguous types galore
21:20:26 <donri> haven't discussed it with author yet :)
21:21:04 <stepcut> what's not like :)
21:21:25 <donri> pardon?
21:21:45 <donri> isn't it relatively trivial to solve the overloadedstrings issue with local type signatures
21:22:10 <stepcut> sorry, I mean.. I hope the discussion with the macro author goes well.. because what's not to like about a port to Text
21:22:33 <luite_> what does it use now?
21:22:42 <stepcut> donri: yes trhsx would have to manually add those type signatures all over the place
21:22:54 <donri> what currently isn't to like is that the pretty rendering does some oddities and the compact rendering is multiline... but there might be workarounds (and still better than string, probably?)
21:23:03 <donri> luite_: string
21:23:17 <luite_> ah
21:23:20 <stepcut> why is compact multiline?
21:23:21 <donri> it's still string for parsing and internal AST stuff though, so far i only ported the rendering code
21:27:31 <hpaste_> donri pasted jmacro prettyprinter at http://hpaste.org/66976
21:29:48 <donri> so you see there's some missing indent for the alert there
21:31:03 <donri> and it actually aligns the braces differently ...
21:32:24 <donri> "(renderCompact x) renders document x without adding any indentation. Since no 'pretty' printing is involved, this renderer is very fast."
21:32:41 <donri> perhaps newlines can simply safely be removed?
21:36:25 <donri> (or just run through hjsmin, although that has more overhead of course)
22:26:48 <donri> stepkut: criterion says my text port is slower
22:30:21 <donri> like 13 microseconds becomes 36 microseconds
22:36:02 <donri> perhaps overhead from T.pack'ing strings in the AST? or wl-pprint-text is simply slower than the pretty package ...
22:39:41 <stepcut> donri: I guess that is something not to like..
22:39:53 <donri> :)
22:57:00 <donri> stepcut: yea it's T.unpack, and worse, overloadedstrings used to use it. upgrading text makes it almost as fast as without text :P still slower, but probably due to AST still using strings for lots of things
22:57:08 <donri> "String literals are now converted directly from the format in which GHC stores them into Text, without an intermediate transformation through String, and without inlining of conversion code at each site where a string literal is declared."
22:57:49 <stepkut> :)
22:57:51 <luite_> yeah that's interesting, probably makes a few of the hamlet templates a bit faster :)
22:58:13 <luite_> I was kind of disappointed though that it was only added now
22:58:14 <donri> yea i think it was yesod devs or users who first reported it on cafe?
22:58:17 <luite_> expected better from bos ;)
22:58:36 <luite_> yeah yesod had huge problems with TH code that generated lots of literals
22:58:38 <donri> bos is boss, except when he's not
22:59:01 <luite_> GHC that used gigabytes of ram, took minutes to compile a single file
22:59:25 <luite_> because the Text conversion code got inlined and then code size just exploded
23:00:08 <luite_> perhaps GHC was optimizing away that code, so this change might not result in a runtime speed improvement, but compile time differnece is huge
23:00:32 <donri> well it did have a noticable performance overhead for my jmacro code
23:00:54 <donri> lots of small string literals for all the javascript syntax
23:01:12 <luite_> I think it's similar for lucius
23:01:54 <donri> well css is a simpler language and most things are already text from parsing right?
23:03:07 <donri> or well, duno how shakespeare-css stores stuff like "auto" internally
23:04:28 <luite_> there was one where there was a huge overhead, and I think julius doesn't need as many separate strings, not sure though
23:04:59 <donri> well, julius doesn't really *have* an AST ;)
23:05:22 <luite_> no but it does have chunks of text, I guess :)
23:06:04 <donri> that come from parsing?
23:06:18 <luite_> from #{...} things
23:06:21 <donri> the issue here is with string literals in the renderer
23:06:31 <luite_> oh
23:07:23 <luite_> meh I have to write some TH now :(
23:07:29 <donri> like if you're rendering a js function, there's a literal for "function", the parens, the commas, the braces, the semicolons...
23:07:44 <donri> i guess that much is similarly true for css...
23:13:36 <donri> stepkut: changing the benchmarks to run on jmPrelude instead of my oneliner made my port faster, despite still having strings in the ast that are packed at rendering time...
23:13:42 <donri> not a lot faster, but faster :D
23:13:53 <stepkut> heh
23:14:22 <donri> a microseconds difference \o/
23:14:27 <donri> our web apps will be ultrafast now!
23:19:21 <donri> actually, millisecond
23:32:02 <donri> perhaps another benefit of doing text directly is you often want text anyway and before that meant you had to pack the string. that's another millisecond according to benchmarks ;)