00:45:51 <alpounet> yet another happstack-powered app: http://diagrams.alpmestan.com/ yay
00:48:47 <stepkut> \o/
00:50:02 <stepkut> I'm factorizing like craaaazy!
01:16:30 <alpounet> well, happstack-lite-powered, to be fair
01:16:54 <stepcut> but.. that is the trick of happstack-lite.. it's just happstack :)
01:17:00 <alpounet> yeah
01:17:04 <stepcut> with out all the useless stuff ;)
01:17:40 <stepcut> woot! bug #14 against fay is closed!
01:18:00 <stepcut> can finish my blog post now :) (I hope)
01:19:12 <alpounet> about what?
01:19:19 <stepcut> happstack+acid-state+fay
01:19:28 <stepcut> +ajax
01:19:31 <alpounet> awesome!
01:19:35 <alpounet> have a sample app to show?
01:19:39 <stepcut> I will
01:19:46 <stepcut> didn't get very far before I ran into that bug :)
01:19:58 <stepcut> but, I will have an ajax chat app (or something similar)
01:20:12 <stepcut> I need to figure out a better excuse for using acid-state though
01:20:29 <stepcut> chat doesn't usually require database storage
01:20:57 <alpounet> "persistent" chat does
01:21:11 <alpounet> but uncommon case, agreed
01:21:27 <stepcut> but, the neat part is that you define your data type once as a normal Haskell data type and you can use that same type in your database, your server, your ajax communication, and on the clientside
01:21:43 <stepcut> there is some serialization/marshaling that happens, but it is entirely automatic
01:21:50 <alpounet> that's pretty awesome yeah!
01:22:02 <alpounet> still have to make it acidic manually though i guess
01:22:11 <stepcut> you, as the developer only have to write type down once and think about it in one form
01:22:41 <stepcut> unlike a traditional system where you would have the SQL representation of a message, and the server-side representation, and the json representation, and the javascript object representation
01:22:45 <stepcut> fuck that
01:22:52 <alpounet> yeah
01:22:56 <alpounet> oh by the way
01:23:10 <alpounet> have fay's performances been good?
01:23:20 <stepcut> so, yeah, persistent chat is the demo I have now, unless I think of something better
01:23:59 <stepcut> I think fay has done much better than the uhc-js backend in some tests.. not sure how it compares overall
01:24:29 <stepcut> based on the approach that it uses, I think fay ought to be able to achieve pretty good performance
01:24:32 <luite> it's a bit difficult to compare because of the different features
01:24:43 <stepcut> yeah
01:25:02 <alpounet> luite, any progress on ghcjs?
01:25:33 <stepcut> any of the haskell->js compiles ought to be able to provide what I want. fay is just the one that does it right now and is easy to get going
01:26:02 <alpounet> yeah
01:26:04 <luite> stepcut: on the nqueens benchmark from the ghc suite it used 63s/220s (chrome/firefox18), haste 25s/71s, ghcjs (new generator) 5.5s/5.5s
01:26:42 <luite> ghcjs old generator 118s/223s, ghc native 0.5s
01:30:47 <stepcut> \o/
01:31:45 <luite> that's pretty much the only benchmark i've tried (other than a very simple fib n = fib (n-1) + fib(n-2) benchmark
01:31:47 <stepcut> I'm definitely not ready to pick a winner is this race yet
01:32:04 <luite> but it also is far from ready for prime time
01:32:28 <stepcut> that's true of all of them :)
01:32:38 <luite> ghcjs ran in under 30MB, other stuff used much more
01:32:43 <luite> 1.8GB in firefox with haste for example
01:34:37 <luite> alpounet: i've been working ont he new generator again this weekend, making the code ready to push to github (not that it will be usable for anyone, but at least you can see what i've been doing)
01:35:04 <alpounet> hah ok
01:35:10 <luite> one 15 line haskell thingy gives me a 13000 line javascript file :p
01:36:55 <alpounet> wow...
01:37:01 <alpounet> no way to get that decreased?
01:38:02 <luite> yeah easily, minification will help a lot
01:38:13 <luite> most of this is really repetitive rts code, so it also gzips very well
01:38:30 <alpounet> ok
01:38:51 <luite> and the number of fast apply paths could be reduced if the program size is really important
01:39:12 <luite> at the cost of some performance and more memory overhead
01:41:32 <luite> https://gist.github.com/3850295 <- the output for the n-queens 12x12 bench
01:42:12 <alpounet> uh :D
01:42:58 <luite> actual program lines 11432 - 12624
01:43:34 <luite> i haven't finished the dataflow analyzer yet, so it has some unnecessary assignments etc
01:43:49 <luite> sp = sp -1; something else; sp = sp + 1; for example
01:44:21 <luite> and the analyzer should also weed out most of the intermediate local variables
01:45:01 <luite> oh this is with a locally defined list type: data List a = Nil | Cons a (List a)
01:45:10 <luite> so this could be compiled without prelude
01:46:34 <luite> alpounet: you can run it, download the file, type node queens.js (or v8 queens.js, js queens.js for plain v8, ionmonkey respectively) and it will print the result in a few seconds
01:47:21 <alpounet> cool!
01:47:36 <alpounet> i think ghcjs has some important role to play considering the performances...
01:47:46 <alpounet> it will when the code gen will be "complete"
01:48:56 <luite> ghcjs is also the only one that can keep the browser responsive while doing a long calculation :)
01:49:14 <luite> since it can yield to the browser from the main loop
01:49:35 <luite> the other compilers aren't fully trampolined, so they have to abort a calculation for that
01:49:38 <alpounet> that's probably going to be the preferred backend in the end
01:50:05 <luite> major pitfall is that ghcjs is also by far the most complex, the new generator
01:50:16 <luite> it requires its own garbage collector
01:50:26 <alpounet> uh
01:51:07 <luite> line 9822 - 10593
01:53:11 <alpounet> rather cryptic, tbh
01:53:12 <alpounet> :p
01:53:19 <luite> hehe yeah generated code
01:55:47 <luite> alpounet: other compilers also need one actually, or at least a partial one
01:55:57 <luite> they leak memory since they don't
01:56:29 <alpounet> my main worries are about 1/ size of generated code when minified/gzipped 2/ performance
01:56:38 <alpounet> you're doing pretty good on the second front
01:56:47 <alpounet> just wondering about the first one "in the end"
01:57:03 <luite> the rts is a one-time thing, that makes up 90% of the code here
01:57:50 <luite> v8 parses this stuff in a fraction of a second
01:59:41 <donri> once the rts stabilizes i imagine we could serve it versioned over a cdn, and even share the cdn? although chrisdone says that compresses worse with closure compiler, so i guess it's a tradeoff
02:00:41 <luite> this code is 13k gzipped after optimization with closure
02:01:02 <luite> that includes the whole rts since i exported everything
02:01:38 <luite> alpounet: what do you think is acceptable as a gzipped distribution size?
02:02:01 <alpounet> i wouldn't know the practical number, not doing enough webdev for that
02:02:35 <alpounet> you would have to check "big" websites, see how much JS they import on every page
02:03:28 <donri> i'd say it also depends on the app. if it's a js-heavy "single page app" an initial load time might be acceptable. if you're just making a call to jquery to set up some effect or something, you want it to be instant
02:04:29 <luite> jquery ui is already quite heavy :)
03:03:13 <donri> stepcut: did you take any look at the cabal 16 issues? sorta wondering if there's a bug we need to report on cabal
03:05:59 <stepcut> nope
03:06:41 <stepcut> i looked at fay, pipes, atom, clckwrks plugins, and some other stuff though :p
03:09:26 <donri> not good enough! you need to do everything, all at once! get to work you lazy bum :D
03:11:23 <stepcut> I also had to host a brunch >:(
03:12:43 <stepcut> I really want to get a new plugins system out for clckwrks this week
03:18:07 <stepcut> what is that css grid template thing that people keep yapping about
03:18:28 <sm> bootstrap! yap! yap!
03:18:52 <stepcut> yeah
03:19:03 <stepcut> i should figure out why people like those
03:19:05 <stepcut> like.. this week
03:19:41 <sm> do, it's awesome. Abstracted a whole bunch of layout stuff for me
03:20:01 <stepcut> k
03:20:25 <stepcut> it is currently relevant to my interests
03:20:43 <stepcut> have to actually make some websites
03:21:01 <stepcut> can use all the help I can get :p
03:21:15 <sm> bootstrap! yap!
03:21:18 <sm> I used it to fix darcs hub
03:21:24 <stepcut> yeah
03:21:31 <stepcut> that's what made me think about it
03:21:40 <stepcut> darcs hub does look pretty nice these days
03:22:32 <stepcut> is there something I should do to make it easier to use bootstrap with HSP  / Happstack?
03:22:45 <donri> also http://foundation.zurb.com/ http://susy.oddbird.net/
03:23:13 <stepcut> hmm
03:23:28 <donri> foundation is less complete than bootstrap, and people say its buttons are ugly, but that otherwise it's better designed than bootstrap, more flexible, easy to work with
03:23:33 <sm> stepcut: maybe just ship with it ? include it in default app, if you have one ?
03:24:12 <donri> chrisdone started out praising bootstrap (using it for the fay ide) but later seemed annoyed at it getting in the way
03:24:30 <stepcut> i should make a basic clckwrks theme that uses bootstrap.. something you would use as a starting point for a real theme
03:26:12 <stepcut> i should do some handstands and go to bed!
03:27:23 <alpounet> is bootstrap twitter's thing?
03:27:31 <donri> yep
03:27:41 <alpounet> i should look into it
03:28:29 <donri> no you should look at foundation! :)
03:29:09 <sm> handstands! /o\
03:29:59 <donri> :D
03:30:04 <alpounet> donri, fine, foundation :P
03:30:10 <sm> 
ACTION does that.. night all

03:33:21 <donri> 
ACTION changes his g+ tagline from "Applied Insanity" to "Practical Contrarian"

04:06:46 <stepkut> ok. I have taken a simple 12 line C program and turned it into a 52-line Haskell program that still contains embedded C as Strings
04:06:48 <stepkut> progress!
04:07:45 <hpaste> stepcut pasted “progress?” at http://hpaste.org/75947
04:08:12 <alpounet> show us the "after"!
04:08:13 <hpaste> stepcut annotated “progress?” with “progress? (annotation)” at http://hpaste.org/75947#a75948
04:08:17 <alpounet> alright :p
04:08:42 <stepkut> :p
04:14:57 <stepkut> the documentation for atom is .. a bit lacking
04:15:18 <alpounet> that's a galois-made library right?
04:15:46 <stepkut> no
04:16:19 <stepkut>  Eaton Corporation
04:16:26 <alpounet> oh alright
04:16:38 <stepkut> It was originally designed and deployed at Eaton Corporation to improve development times and ease of verification of hydraulic hybrid systems in buses and trucks.
15:27:16 <levi> Arduino coding in haskell?
15:48:21 <stepcut> yeah
15:48:45 <stepcut> would be nice to do bare metal haskell on raspberry pi
15:48:58 <stepcut> right now I was just exploring atom+arduino
20:18:55 <stepcut> raspberry pi appears to get around ~380 reqs/second on the pong test using happstack :p
20:25:52 <mightybyte> happstack must not be web scale!
20:25:53 <mightybyte> :P
20:26:13 <sm> happstack on raspberry pi, nice :)
20:27:41 <stepcut> just need a cluster of raspberry pi's !
20:27:58 <sm> and cloud haskell!
20:28:02 <stepcut> :)
20:42:17 <stepcut> i ran the test over spotty wifi, so I'll try again after I dig out the ethernet cables
23:10:35 <stepkut> oh, hm. fay doesn't support QQ :)
23:49:05 <stepkut> well.. #104 is fixed, but I found a very similar bug still, https://github.com/faylang/fay/issues/112
23:49:09 <stepkut> guess I am done for today :)