00:19:13 <stepcut> :)
00:22:49 <donri> bedtime
00:23:37 <stepcut> sleep tight!
11:43:02 <donri> har har http://www.doxdesk.com/updates/2009.html#u20091116-jquery
11:43:20 <donri> (though the points regarding innerHTML don't apply to our case)
14:28:21 <donri> maybe a js vm wouldn't really mean less bytes over the wire than gzipping the js; if it really is full of repetition it should compress really well?
14:50:13 <luite> a js vm?
14:57:00 <donri> we discussed it yesterday
14:58:17 <luite> oh btw have you seen hamismacks ghcjs branch?
14:58:26 <donri> nope
14:58:32 <donri> what it do?
14:58:49 <luite> it has a linker that removes unused function
14:58:50 <luite> s
15:00:22 <luite> and the rts is better than the original ghcjs, with mvars, threading among other thigns
15:01:44 <donri> is it more effective than closure?
15:02:06 <donri> (in any case great to not depend on a jre for your build system)
15:02:13 <luite> the automatic xmlhttprequest module dependency loading code was removed, but it does generate a loader script that splits dependencies into bundles
15:02:24 <luite> it uses closure
15:02:52 <donri> aha
15:02:56 <luite> although i think it should be possible to swap out closure for something else
15:03:33 <luite> i won't be able to use this linker, but i like the other changes
15:03:45 <luite> it uses the google library for arbitrary precision integers
15:03:58 <luite> instead of integer-simple
15:07:01 <luite> might it be a good idea to make a ghcjs organization on github? with wiki, issue tracker etc?
15:07:18 <luite> it seems like more people are interested, but not many are actually working on it
15:09:35 <donri> +1
15:18:59 <luite> the code size is a bit biggish, but i think that if you're careful to write some client-side lib that doesn't pull in huge dependencies, it should probably work
15:19:40 <luite> probably means going for something a bit leaner than aeson for manipulating json data, perhaps an aeson drop-in replacement written in js?
15:23:19 <donri> or ffi to the browser's json apis or jquery/yui etc?
16:00:44 <luite> donri: yes, ,but it would be nice if you could still use the same api
16:01:33 <donri> true