11:34:41 <fasta> I have a HelloWorld application, I run ghci HelloWorld.hs, and I run main, run the browser, change HelloWorld, do C-c in ghci and run main again, do F5 in the browser, but no change is visible. Why not?
11:35:16 <fasta> After one minute or so, a change is visible after repeated reloading.
11:36:07 <fasta> Using a new browser window does show an updated version, so while there might be some cacheing going on, I think that's a bug.
11:36:26 <fasta> (Certainly if it's the first example in a tutorial)
11:36:56 <Entroacceptor> fasta: try Shift-F5
11:37:21 <Entroacceptor> browser cashes are nasty
11:37:32 <fasta> Entroacceptor: ok, that works.
11:37:45 <fasta> Entroacceptor: is there something which already automatically reloads the browser on file save?
11:37:48 <Entroacceptor> if you're doing web development, there are some very helpful plugins for the good browsers
11:38:27 <Entroacceptor> firebug for example (firefox) can disable the cache
11:39:02 <Entroacceptor> fasta: I've seen it, but I don't remember if it was for haskell
11:39:06 <Entroacceptor> *happstack
11:39:18 <Entroacceptor> and that depends on a bit of pre-setup
11:45:39 <donri> fasta: hm, i doubt a hello world app sends browsing headers...
11:45:43 <donri> could you hpaste it?
11:45:58 <fasta> donri: first thing in the tutorial.
11:46:12 <donri> crash course or lite?
11:46:15 <fasta> crash
11:46:43 <donri> weird
11:47:14 <donri> also see maybe https://github.com/chrisdone/bdo
11:48:39 <donri> are you on windows? i think C-c is broken on ghci windows
11:48:49 <fasta> donri: no, I am not on Windows.
11:49:05 <donri> what does curl -I localhost:8000 show
11:49:20 <donri> also, what browser are you using?
11:53:46 <Entroacceptor> oh
11:53:57 <Entroacceptor> I can't get a response from netcat
11:54:42 <Entroacceptor> that's breaking httpd
11:54:43 <Entroacceptor> http
11:55:13 <fasta> Does HAppstack also include some kind of Haskell->JS compiler or has that been left out on purpose?
11:55:40 <donri> Entroacceptor: try nc -C
11:56:07 <donri> fasta: nothing included, but you could use fay or ghcjs
11:56:30 <fasta> donri: what's the compilation speed of those things?
11:56:48 <donri> what do you mean?
11:56:48 <fasta> donri: in my experience lots of those tools recompile the run-time system over and over again.
11:57:00 <fasta> donri: that is; there is no incremental compilation.
11:57:08 <fasta> donri: no incremental compilation => garbage.
11:57:14 <Entroacceptor> donri: -C is an invalid option
11:57:24 <donri> Entroacceptor: huh, what system you on
11:57:30 <Entroacceptor> but every other webserver sends the response after two RETs
11:57:44 <Entroacceptor> this is GNU netcat 0.7.1
11:57:46 <fasta> I also have a -C option.
11:57:50 <donri> Entroacceptor: http requires crlf i think
11:58:56 <Entroacceptor> oh, right
11:59:35 <donri> works with nc -C here
11:59:46 <donri> so tldr happstack is spec compliant, the other servers you tested not :p
12:00:25 <Entroacceptor> donri: oh, accepting it is still in specs ;)
12:01:17 <donri> fasta: duno ghcjs but it might be incremental in that it is built as a ghc backend. fay is not incremental last i checked, though we've investigated caching parses/compilations. but why do you care?
12:02:24 <donri> fasta: do you expect to have an insanely large client-side code base or are you compiling dynamically or something?
12:02:47 <donri> Entroacceptor: oh?
12:02:48 <fasta> donri: I don't like slow tools.
12:02:57 <adnam> it's not slow
12:03:06 <donri> fasta: it's a matter of a second or so on compile-time :p
12:03:15 <Entroacceptor> donri: or maybe not, but I'm confused now. Every other webserver gave me what I wanted
12:03:21 <fasta> donri: a second is a really long time.
12:03:39 <donri> Entroacceptor: well webland is filled with hacky workarounds for faulty servers and clients
12:03:39 <adnam> it's fast enough to recompile on every request in development without it being annoying
12:03:57 <fasta> adnam: how many lines of code are you talking about?
12:04:18 <fasta> adnam: (including the use of libraries, etc.)
12:04:53 <Entroacceptor> amazing, gnu netcat has fewer options than the openbsd one
12:05:22 <donri> fasta: anyway we measured the parsing (haskell-src-exts) to be the slowest part of fay, and since the AST is a Data we could serialize them with binary. feel free to implement it ;)
12:05:23 <adnam> we use fay mostly to interface with js libs, meaning the only overhead added is the ffi bindings
12:06:24 <fasta> Is anyone actually working on the sharding part, btw?
12:06:36 <donri> fasta: note that fay isn't really a full-fledged compiler. it's more like something in between a compiler and something like coffeescript.
12:06:51 <donri> fasta: nope
12:07:05 <fasta> donri: so, why does the website says otherwise?
12:07:16 <donri> does it?
12:07:40 <donri> i think it mentions the possibility of a gsoc, but the student didn't have the time for it
12:08:16 <donri> oh and that was replication even, not sharding
19:52:20 <donri> struggling to set up redis and couchdb; acid-state has me forgetting how much i hate sysadmin work -.-
20:04:09 <adnam> yep sucks :(
20:38:19 <donri> is good fun to watch these icfp videos where these awesome hackers run unconfigured linux desktops with unconfigured vim/emacs and do things like hold backspace to delete words and lines in bash
20:39:03 <donri> same with stepcut's screencast ;)
21:45:00 <LambdaDusk> once again I have a type error I can't solve
21:45:10 <donri> do tell
21:45:58 <adnam> why do these awesome hackers not copy their configs? :D
21:46:37 <donri> adnam: no it's on their own laptops
21:46:50 <donri> my point is they don't seem to *have* configurations, or know about key shortcuts
21:47:19 <LambdaDusk> donri:
21:47:19 <LambdaDusk> No instance for (Happstack.Foundation.HasAcidState IO ModelState)
21:47:19 <LambdaDusk>       arising from a use of `query'
21:47:50 <donri> LambdaDusk: you're calling query from a plain IO context
21:47:53 <adnam> donri: :(
21:48:03 <LambdaDusk> donri: no I used liftIO
21:48:11 <LambdaDusk> oh wait, no liftIO?
21:48:22 <LambdaDusk> I always needed liftIO before when query'ing
21:48:23 <donri> LambdaDusk: yea, liftIO takes a plain IO
21:48:41 <LambdaDusk> grml
21:48:44 <donri> LambdaDusk: yea, no, query already does liftIO for you here
21:48:46 <LambdaDusk> works now, thanks
21:49:05 <donri> it's a magical query that knows how to find your opened acid-state and how to run in MonadIO
21:52:28 <LambdaDusk> well any sophistically analysed magic can't be distinguished from technology so I will just stare at the non-existent documentation until I get it
21:53:21 <donri> yea, happstack-foundation isn't even announced yet, and this is probably in part why :)
21:53:44 <donri> the method used is documented in the crash course though
21:54:09 <LambdaDusk> yay for early adoption
21:54:14 <donri> =)
21:54:41 <LambdaDusk> I think it was because I always used query' and not query
21:55:04 <LambdaDusk> without my bug reports, there would be holes in foundation's release
21:55:18 <LambdaDusk> that's my excuse to be able to sleep at night
21:58:51 <donri> if you use query' you shouldn't need liftIO
21:59:32 <donri> but you would need to pass the acid handle to it
21:59:57 <donri> foundation's query is basically getAcidState >>= query'
22:13:19 <LambdaDusk> is there any way to tell jmacro to generate non-minimised code for development?
22:16:30 <luite> uh renderJs code isn't exactly minified is it?
22:18:35 <LambdaDusk> but in one like
22:18:45 <LambdaDusk> difficult to set breakpoints ^^
22:18:45 <donri> luite: we render in OneLineMode which is somewhat minified
22:19:25 <LambdaDusk> what he said
22:19:27 <donri> LambdaDusk: you'd have to do a newtype wrapper with custom ToMessage instance, or render manually
22:19:33 <luite> oh i forgot there was happstack integration
22:19:39 <LambdaDusk> oh
22:20:30 <luite> gerhsom doesn't seem to want to support `` antiquotes unfortunately
22:20:33 <donri> or possibly don't use the happstack-jmacro package and write your own ToMessage JStat
22:20:38 <donri> luite: aww
22:22:18 <donri> LambdaDusk: it's not too hard, see http://www.happstack.com/docs/happstack-jmacro-7.0.1/doc/html/happstack-jmacro/src/Happstack-Server-JMacro.html
22:22:39 <donri> mainly look at instance ToMessage JStat, the rest is optional
22:23:13 <LambdaDusk> sure but I use my jmacro from within hsp
22:23:52 <luite> there are also some other issues that i reported, maybe i'll send him some patches
22:23:52 <donri> aha
22:24:06 <luite> unfortunately he also doesn't want to make assignment an expression :(
22:24:36 <donri> LambdaDusk: http://www.happstack.com/docs/hsx-jmacro-7.1.1/doc/html/hsx-jmacro/src/HSX-JMacro.html see the EmbedAs... instances mainly
22:25:32 <LambdaDusk> this looks as if I can use hsp within a jmacro
22:25:34 <luite> admittedly having it being just a statement makes dataflow analysis a tiny bit simpler
22:25:58 <donri> LambdaDusk: yep
22:26:07 <donri> it's documented here http://www.happstack.com/docs/hsx-jmacro-7.1.1/doc/html/hsx-jmacro/HSX-JMacro.html
22:26:11 <luite> LambdaDusk: have you never run into parsing problems with jmacro?
22:26:29 <LambdaDusk> luite: Only when trying to make empty functions
22:26:33 <luite> hmm
22:26:40 <LambdaDusk> somehow jmacro doesn't like 'em
22:27:13 <LambdaDusk> oh and this weird alternative syntax for functions, that did to not work at all
22:27:26 <LambdaDusk> or rather produced unpredictable output
22:27:28 <luite> for(var i=arr.length-1;i>=0;i--) translates to for(var jmId_0=arr.length(-1);jmId_0>=0;jmId_0--)
22:27:33 <donri> luite is using jmacro to write a compiler so his needs are probably more complex than your average "make some calls to jquery" web apps ;)
22:27:50 <LambdaDusk> yeah sorry for that
22:28:00 <donri> sorry for what?
22:28:03 <luite> ?
22:28:12 <luite> did you write that part of the parser? :p
22:28:19 <LambdaDusk> i don't think so
22:28:37 <LambdaDusk> I keep trying but whenever I try to write any parser it's a failure
22:28:39 <luite> donri: it's still quite repetitive though, most of de generator
22:28:49 <LambdaDusk> which strangely fits to any haskell project =/
22:28:58 <luite> the most complex javascript bits generate the rts
22:29:27 <donri> what is the rts written with?
22:29:57 <donri> "ghcjs, of course!"
22:30:26 <luite> the outerloop: do { } while((x=work.pop())!==undefined); <- contains 4 things that are unsupported in the current hackage version of jmacro
22:31:03 <donri> :)
22:31:20 <donri> what's the 4th?
22:31:36 <luite> fortunately 3 have been added on my request, the remaining one is the assignment expressions
22:31:57 <donri> do-while, assign-expr, undefined, what else?
22:31:59 <luite> donri: labels, !== operator, do-while loops
22:32:13 <luite> those have been added now
22:32:34 <donri> oh, i was thinking !== operator but i was stuck in haskell mode and didn't consider how operators are a fixed set
22:33:07 <donri> do you regret using jmacro?
22:33:13 <luite> the rts is jmacro btw
22:33:22 <luite> nah not really, i don't think the alternatives are really better
22:34:14 <luite> having a simplified javascript makes it easier to do dataflow analysis
22:34:37 <luite> it was just a bit less finished than i hoped :p
22:34:45 <donri> heh yea
22:34:51 <donri> not a lot of users
22:35:10 <donri> and besides yours no complex uses :p
22:35:14 <LambdaDusk> how many projects are there to make haskell compile to js?
22:35:48 <luite> at least 4
22:36:14 <luite> i think one of the less known haskell compilers might have a js backend too
22:36:38 <luite> but otherwise fay, ghcjs, haste, uhc-js
22:37:16 <LambdaDusk> any of them fruitful?
22:38:09 <luite> f_a_y is probably the easiest to get started with, chrisdone uses it for his own work
22:39:14 <luite> ghcjs probably the least finished
22:39:41 <donri> i thought ghcjs was the most complete
22:40:30 <luite> yeah depends on how you see it, ghcjs has the most complete rts but it's more difficult to install than haste and uhc-js
22:41:09 <luite> also i'm working on a new backend instead of making it more userfriendly. and uhc-js and haste both come with a few libraries ,ghcjs not really
22:42:18 <donri> well, that's what we have fay for, something "good enough" until ghcjs is awesome, so take your time :)
22:42:34 <donri> i'd rather have ghcjs be awesome than, uhm, hasted
22:44:42 <adnam> tish
22:44:49 <LambdaDusk> donri: http://www.youtube.com/watch?v=rlzaNtzLrF8
22:48:22 <luite> hehe
22:48:33 <luite> i'm working on the garbage collector now
22:49:02 <adnam> \o/ i broke a type system
22:49:12 <luite> it's a 2-generation compacting collector so far, but i probably need to add some optimization later
22:49:20 <LambdaDusk> because JS has no GC?
22:49:31 <luite> to reduce the amount of moving of large objects
22:49:36 <luite> LambdaDusk: yeah
22:49:45 <adnam> O_o
22:50:50 <LambdaDusk> good to know
22:50:55 <luite> :p
22:51:12 <LambdaDusk> a better GC for Haskell wouldn't be too bad either
22:53:28 <luite> js does have a gc of course, but it looks like it's tuned for common javascript usage patterns (who'd have thought), it appears to be a lot slower with haskell code, which allocates a huge amount of short-lived objects, and the main loop (trampoline) probably breaks escape analysis in many cases
22:54:20 <LambdaDusk> hm yeah I can see what you mean
22:55:10 <LambdaDusk> the total lack of value re-use in haskell, that is the problem... but I heard GHC re-uses them anyway when it sees the old value will the scrapped anyway
22:55:12 <luite> it's a bit difficult to say for sure, i've only ran some tests with manually written code in that style :)
22:55:51 <luite> hm, i don't think ghc reuses heap objects, it does try to reuse stack positions as early as possible
22:57:07 <LambdaDusk> I can't say where I heard it but I always that in, for example "\x -> x + 1", the object for x will be re-used for x+1, unless referenced again in calling code
22:57:28 <luite> oh but that's very likely stack
22:57:53 <luite> or even registers
22:58:26 <LambdaDusk> oh
22:58:35 <luite> with enough inlining, that function is called with x :: Int# in R1, and just sets R1 = R1 + 1, and then jumps ot the top of the stack
22:58:35 <LambdaDusk> all right then
22:58:35 <donri> LambdaDusk: well for example (:) creates a link between two values, but those values themselves aren't copied AFAIK
22:59:00 <luite> that only happens when demand analysis kciks in and decides it's strict enough to unbox this stuff :)
22:59:19 <luite> that's teh Cmm level, see -ddump-cmm for that
22:59:23 <LambdaDusk> and the GC of Haskell stops the process to do its work, afaik
22:59:32 <luite> yeah
22:59:39 <luite> but it is multithreaded now
22:59:55 <donri> i wantonly a JIT in ghc
23:00:08 <LambdaDusk> just know it can cause problems in some realtime applications
23:00:18 <LambdaDusk> donri: LLVM?
23:00:40 <donri> does -fllvm JIT?
23:00:53 <luite> no
23:01:09 <luite> donri: do you want it to dynamically inline things for you?
23:01:33 <donri> http://youtu.be/PtEcLs2t9Ws
23:01:40 <donri> luite: something like that
23:01:51 <donri> dynamic SPECIALIZE and whatnot
23:01:57 <luite> ah right, i was just going to suggest that traces based on arguments might wirk
23:01:58 <luite> work
23:02:04 <luite> in particular the dictionaries
23:02:53 <LambdaDusk> donri: The LLVM package lets you write llvm code in a DSL that is JIT'ed if you want it do
23:03:04 <LambdaDusk> combine with GHC-api -> profit
23:03:54 <donri> i just want -fjit-my-code-plz, don't want to do it myself ;)
23:04:33 <luite> hm they should link to the slides
23:04:39 <luite> i don't want to wait 25 minutes
23:05:43 <donri> heh, the videos aren't great. low quality, bad sound, no sound in some of them. but, nice that they're up so quick.
23:06:19 <luite> yeah 360p what's with that... there should be 1080p at least
23:06:46 <LambdaDusk> and some special effects with alien battles
23:06:53 <donri> some of them are 480p ;)
23:07:22 <luite> meh
23:07:24 <donri> of course the sound is broken in all the most awesome talks i wanted to watch
23:07:26 <LambdaDusk> wow the code is messed up in that quality
23:07:35 <luite> almost all dslrs can take very high quality 1080p now
23:08:00 <luite> oh wait there migth be a problem there, the fat32 filesystem on sd cards
23:08:40 <LambdaDusk> donri: For JIT, compile to the JVM?
23:09:04 <donri> duno if that would be optimized for haskell
23:09:16 <donri> or is it low-level enough at that point that it's all the same?
23:10:19 <luite> i don't think jvm uses a trace compiler?
23:10:39 <LambdaDusk> unfortunately not, JVM lingo uses lots of class-talk
23:11:56 <luite> i'm not even sure if any of the javascript engines uses traces anymore
23:14:37 <LambdaDusk> welp I better go to bed before I type even more stupid stuff
23:14:40 <LambdaDusk> g'bye
23:21:05 <luite> hmm
23:21:24 <luite> i wonder how important it really is to throw out allocations
23:21:29 <luite> they're very cheap with ghc
23:21:52 <luite> though maybe running through the allocation area will hurt caching
23:40:39 <luite> blah i spend far more time fixing bugs in my test cases than in the gc