01:12:56 <HugoDaniel> http://pastie.org/1076398
01:12:59 <HugoDaniel> why ? :(
01:13:17 <HugoDaniel> Not in scope: type constructor or class `NFData'
01:14:35 <aavogt> didn't this get addressed before?
01:15:00 <aavogt> you need to require an older parallel, ie. --preference='parallel < 0.2' or some 10^n of that
01:16:12 <aavogt> or modify those packages to import deepseq instead
01:17:23 <HugoDaniel> ok
01:17:24 <HugoDaniel> thanks
01:17:36 <aavogt> modules from deepseq
01:20:14 <HugoDaniel> still doesn't work
01:20:16 <HugoDaniel> i hate this
01:20:47 <aavogt> maybe constraint
01:21:57 <HugoDaniel> ok, done
01:22:15 <HugoDaniel> i have downloaded the .tar.gz and changed the cabal and the modules to import deepseq instead
01:22:22 <HugoDaniel> :/
01:23:01 <aavogt> whoever maintains those modules should probably know
01:24:10 <HugoDaniel> dons is the name that hackage throws
01:24:34 <stepcut> HugoDaniel: yeah, I sent dons an email a few days ago.. didn't hear back. You should send another one :)
01:25:28 <stepcut> Maybe we can axe the dependency on strict-concurrency altogether.. that would be nice. But I have not looked at the code yet.
01:27:24 <HugoDaniel> :D
03:15:32 <dons> yo yo
03:16:03 <stepcut> dons: yo yo! fix strict-concurrency :p
03:16:24 <stepcut> pretty please
03:17:57 <dons> aah ok!!!!
03:18:02 <dons> will do tonight.
03:20:13 <stepcut> :p
03:20:30 <stepcut> I dropped the dependency on HaXml in 0.6, btw
03:21:01 <stepcut> well, in what will soon be 0.6
03:27:56 <siracusa> `cabal install --reinstall --ghc-option=-DINTERACTIVE' is broken in happstack-util-  :-(
03:28:26 <stepcut> siracusa: hmm, we should fix that
03:28:37 <stepcut> siracusa: what error ?
03:29:47 <aavogt> are those CPP flags actually for cabal?
03:30:19 <siracusa> stepcut: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=28575#a28575
03:30:19 <aavogt> siracusa: if you   ghci -DINTERACTIVE -XCPP ...   isn't that good enough?
03:31:18 <siracusa> aavogt: I don't think this will be enough, since INTERACTIVE is used in happstack-util
03:31:23 <stepcut> siracusa: the logM stuff you can comment out. For the AsyncException, maybe try importing Control.OldException? Not really sure.. i
03:31:29 <aavogt> maybe it's dependencies need to be compiled with different flags too
03:32:03 <aavogt> you can --constaint="base < 4" for that oldexception stuff
03:32:07 <stepcut> aavogt: nah, the primary error is about an Exception. I suspect that code has not been compiled since the exception system was updated
03:32:14 <aavogt> I dunno if that's going to make a difference
03:32:44 <stepcut> aavogt: which might require the newer base elsewhere
03:32:45 <aavogt> logM doesn't sound like it's involved with any exceptions
03:32:58 <stepcut> aavogt: right, it can be commented out
03:33:26 <aavogt> INFO might be a CPP macro that should have been defined
03:33:50 <siracusa> `w (Left (ThreadKilled)) = return ()' expected result type is IO a, can I use undefined there?
03:33:55 <aavogt> it's hard to tell, even if you had the source
03:34:31 <stepcut> aavogt: no, INFO is a log level related to logM
03:34:40 <stepcut> aavogt: which both come from hslogger
03:34:52 <stepcut> aavogt: but it would be nice to replace hslogger with something better/faster
03:36:02 <stepcut> siracusa: dunno.. not enough context
03:36:05 <aavogt> stepcut: the alternative inlines the calls to write some log for sure?
03:36:21 <stepcut> aavogt: inlines ?
03:36:40 <aavogt> stepcut: why is hslogger slow?
03:37:00 <siracusa> stepcut: It's `forever :: IO a -> IO a -- | A version of forever that will gracefully catch IO exceptions and continue executing the provided action.'
03:37:32 <stepcut> aavogt: dunno. Even if you aren't actually writing the logs it still takes a lot of time. If I comment out the 'logM' line in the handler loop I get a 10-15% performance increase in requests/second
03:38:30 <aavogt> so deciding on logging at compile-time could help
03:39:19 <stepcut> siracusa: hmm, I can't see how that ever worked. I think someone must have added the type signature after the fact..
03:39:56 <stepcut> siracusa: I think you need to move, forever :: IO a -> IO a, inside the #ifndef INTERACTIVE
03:43:49 <siracusa> stepcut: Compilation was okay, but the server thread still doesn't get killed.
03:46:10 <siracusa> `add -DINTERACTIVE to the command line and use the function happsKill from the prompt'. Is there an replacement function for happsKill?
03:49:01 <stepcut> maybe you do something with, registerResetAction ?
03:50:03 <stepcut> maybe, reset instead of happsKill ?
03:50:35 <stepcut> yeah, try reset
03:54:57 <siracusa> reset doesn't return
03:56:29 <stepcut> :(
04:09:01 <siracusa> I don't know much about MVars, but if I understand this correctly `modifyMVar_ happsThreadList (\xs -> return (killThread x:xs))' a list of killThread actions is constructed for all forks. But when do they get evaluated?
04:10:32 <siracusa> Ahh, this is what reset does
04:11:57 <stepcut> yeah
04:17:09 <siracusa> I checked the threadList, it's empty after the reset. Though, the ports are still bound.
04:23:42 <stepcut> :(
04:23:54 <stepcut> clearly that feature needs some updating
04:27:24 <siracusa> Maybe it's related to this one http://hackage.haskell.org/trac/ghc/ticket/3937 but the proposed workaround is exactly that is done now.
21:16:29 <dons> stepcut: does the happstack site have a list of live web sites running on happstack?
21:16:34 <dons> e.g. including gitit.net darcs.net http://www.silkapp.com/ etc
21:16:41 <dons> the snap guys have a list, and its a FAQ.
21:18:49 <stepcut> silkapp.com headers claim it is ruby on rails :-/
21:19:49 <stepcut> < Server: Apache
21:19:49 <stepcut> < X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.14
21:20:29 <stepcut> perhaps the actual version you can get to is snap powered
21:23:29 <stepcut> I would like to start a list, and do a bunch of other things too. but haven't had time..
21:23:37 <stepcut> the source for the site is available if someone wants to add it ;)