03:23:16 <rlpowell> Server error: HandshakeFailed (Error_Misc "thread killed") -- Well, *that's* helpful.  -_-
03:24:26 <rlpowell> Any ideas on how to debug that sort of thing?
04:04:30 <stepkut> um
04:04:37 <stepkut> is that using happstack-server-tls?
04:05:14 <stepkut> the HandshakedFailed thing is not part of happstack-server
04:05:32 <stepkut> the 'thread killed' is something that happstack could cause if a thread goes 30+ seconsd with out sending or receiving data
04:05:59 <rlpowell> 04-20:08 <     stepkut> the HandshakedFailed thing is not part of happstack-server -- Huh.
04:07:57 <rlpowell> It must be my outbound stuff, then.
04:08:23 <rlpowell> What's an appropriate solution to the 30 second thing if something actually needs to run for a while?
04:08:51 <rlpowell> Oh, it could be the auth code as well, looks like.
04:10:59 <donri> are you using browserid or somesuch?
04:11:57 <rlpowell> Google openid.
04:12:06 <rlpowell> Via happstack authenticate.
04:12:20 <rlpowell> But I also run various HTTP stuff *outbound* to other sites, to retrieve data, so it could be there too.
04:12:20 <donri> no, nevermind. handshakefailed is a tls error http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:handshakefailed
04:12:37 <rlpowell> Yes.
04:12:42 <donri> ah yea it could be http-conduit
04:13:11 <donri> is that what you're using for the outbound?
04:13:35 <stepkut> which raises the question.. are you using happstack-server-tls?
04:13:58 <donri> and yea it's a bit silly how bad runtime errors are in haskell
04:14:06 <donri> there's work in ghc to improve things
04:14:52 <stepkut> if you needed to do a really long calculation before sending a response you would, in theory, manually tickle the timeout now and then to assure the server you are still alive. But I am not sure if that functionality is exposed at the moment
04:14:53 <donri> stepkut: except happstack isn't using the tls package
04:15:09 <stepkut> yeah.. it uses opensll
04:15:11 <stepkut> openssl
04:15:20 <donri> which doesn't seem to have that exception
04:15:24 <stepkut> so, who uses the tls library?
04:15:46 <donri> but http-conduit has the same exception [name]
04:16:11 <stepkut> seems like it is probably http-conduit then that is getting annoyed at something taknig too long
04:16:16 <stepkut> it also uses a timeout manager
04:17:08 <donri> actually
04:17:09 <donri> http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:error_misc
04:17:16 <donri> it is tls not conduit :p
04:17:43 <rlpowell> 04-20:16 <     stepkut> which raises the question.. are you using happstack-server-tls? -- I don't think so, no.
04:17:45 <donri> although the latter uses the former
04:18:20 <rlpowell> 04-20:18 <     stepkut> so, who uses the tls library? -- That error greps out of ControlVAuth in my copy of happstack-foundation.
04:18:25 <rlpowell> So *something* in the auth uses it.
04:19:33 <donri> authenticate uses http-conduit which uses tls so that sounds plausible
04:20:01 <donri> so presumably it is trying to connect to google openid over https and failing for some reason
04:20:12 <rlpowell> *nod*
04:20:32 <rlpowell> Although auth had already worked, so it's more likely it was my own code, which I believe does use http-conduit.
04:20:48 <rlpowell> I was mentioning that the auth code could potentially do it as an aside.
04:21:07 <stepkut> fix your code :p
04:21:31 <rlpowell> Huh?
04:21:41 <rlpowell> Well, that's exactly what I was asking: how do I fix my code?  :)
04:21:59 <rlpowell> So as to give more informative errors, if nothing else.
04:22:13 <stepkut> first find the call that is getting thread killed
04:23:07 <stepkut> doesn't ghci have some sort of backtraces for exceptions these days?
04:23:19 <rlpowell> The code didn't exception out, though.
04:23:25 <rlpowell> It keeps running normally.
04:23:30 <rlpowell> All I have is a web page with that error.
04:23:32 <stepkut> sure
04:23:36 <rlpowell> I have no idea how to find the code with the problem.
04:23:36 <stepkut> only one thread got killed
04:23:43 <rlpowell> Besides binary search, basically.
04:23:53 <stepkut> that's how I find pretty much every bug :)
04:23:56 <rlpowell> Heheheh.  'k.
04:23:57 <donri> threads dying doesn't kill the main thread in haskell
04:24:15 <rlpowell> That's what I'm about to set up; some debugging printing.
04:25:08 <stepkut> printf-style debugging.. if it's good enough for Lennart Augustsson, it's good enough for me :)
04:26:01 <donri> you can get half assed stack traces with profiling options but they're nothing like what you're used to from dynamic languages
04:27:05 <donri> at least it seems https is involved so you could target those first
04:27:16 <rlpowell> *nod*
04:27:54 <stepkut> sorry I'm not more helpful at the moment, trying to build some motorized cat ears
04:28:00 <stepkut> gotta get it done tonight
04:31:48 <rlpowell> Oh, I'm OK; I'm busily installing some debugging stuff.
04:31:55 <rlpowell> Also, that sounds adorable.
04:33:17 <donri> ^_^
04:51:28 <stepkut> I need to start designing my own pcbs
05:07:32 <rlpowell> Is it normall for happstack-based "cabal install" to take multiple minutes?
05:09:35 <donri> yes, if you don't already have most of the dependencies installed
05:09:37 <stepkut> depends how much it is installing
05:10:01 <donri> with latest cabal-install on multicore try -j
05:10:08 <stepkut> and how fast your machine is
05:10:18 <stepkut> took many hours on my 256MB Raspberry Pi
05:10:18 <rlpowell> I have all the dependencies installed.
05:11:05 <rlpowell> My machine is quite nice.
05:11:20 <rlpowell> 04-21:13 <       donri> with latest cabal-install on multicore try -j -- I can't see what could be parallelized?
05:11:25 <rlpowell> It's just linking.
05:11:51 <donri> it only helps when installing multiple packages (e.g. deps)
05:12:01 <rlpowell> Right, but I'm not.
05:12:10 <donri> yea that sounds weird then
05:12:19 <rlpowell> Yeah.
05:12:37 <rlpowell> Jan 04 21:14:24 Loading package happstack-authenticate-0.9.8 ... linking ... done.
05:12:40 <rlpowell> Jan 04 21:15:49 Linking dist/build/ControlV/ControlV ...
05:12:58 <rlpowell> No idea what it's doing there.
05:13:08 <rlpowell> ACTION tries -v
05:13:20 <donri> are you using a network filesystem? are you installing with --enable-tests?
05:13:39 <rlpowell> No, don't think so.
05:13:42 <donri> hm more than a minute to load a package
05:14:13 <rlpowell> Huh.
05:14:19 <rlpowell> Yeah, -v adds no new information.
05:14:35 <rlpowell> It looks like it really *is* spending a minute plus on happstack-authenticate-0.9.8
05:14:57 <donri> -v3 or something?
05:15:23 <rlpowell> Woah.
05:15:32 <rlpowell> ByronJohnson: 04-21:18 <       donri> -v3 or something?
05:15:38 <rlpowell> That's a lot of output.
05:15:43 <donri> or -v2, 3 might be overkill
05:15:45 <rlpowell> Jan 04 21:18:46 Result size of Simplifier iteration=1 = 196493
05:15:51 <rlpowell> ^^ Dozens of those.
05:16:17 <rlpowell> Which ... you'd think it'd do that once and then cache the result?  WTH?
05:16:20 <donri> it says 1 is default but i don't know if that's with or without -v alone
05:16:33 <donri> which Cabal/cabal-install versions?
05:16:37 <rlpowell> The biggest gap is:
05:16:38 <rlpowell> Jan 04 21:18:59 *** Tidy Core:
05:16:38 <rlpowell> Jan 04 21:19:41 Result size of Tidy Core = 125485
05:16:44 <donri> cabal --version
05:17:13 <rlpowell> (synciki)rlpowell@vrici> cabal --version
05:17:13 <rlpowell> cabal-install version
05:17:13 <rlpowell> using version of the Cabal library
05:17:32 <rlpowell> I can post the whole output if anyone cares.
05:18:01 <donri> i'm at a loss either way i suspect
05:18:04 <rlpowell> 'k.
05:18:26 <donri> i don't suppose it's swapping a lot or something?
05:19:23 <donri> ghc loves to eat memory when compiling
05:19:58 <ByronJohnson> rlpowell: Could you paste the output of cabal install -v after running --clean?  Different optimization levels and using different packages can make a difference
05:20:05 <ByronJohnson> s/--clean/cabal clean/
05:21:25 <donri> ByronJohnson: weird thing is it seems to be just *loading* the package from the db that is taking time
05:21:43 <donri> rlpowell: ze experts are in #hackage anyway
05:22:11 <rlpowell> donri: Are they?  'k.
05:22:23 <rlpowell> (synciki)rlpowell@vrici> cabal clean
05:22:23 <rlpowell> cleaning...
05:22:23 <rlpowell> Error while removing dist/: dist: removeDirectory: inappropriate type (Not a directory)
05:22:27 <rlpowell> -- lol.
05:22:28 <rlpowell> Can't handle symlinks.
05:23:28 <rlpowell> donri: FWIW, no, it is not swapping or anything.
05:23:39 <rlpowell> It's using *all* the CPU, though.
05:23:49 <rlpowell> Why #hackage ?
05:24:02 <donri> that's the channel for cabal
05:25:48 <rlpowell> Ah.
05:26:02 <rlpowell> ByronJohnson: Jan 04 21:26:58 *** Tidy Core:
05:26:02 <rlpowell> Jan 04 21:27:40 Result size of Tidy Core = 125485
05:26:25 <rlpowell> OK, I need to go to bed.
05:28:15 <donri> there are things that can make compilation slow even for moderately sized sources, like lots of template haskell or deriving certain classes
05:28:35 <ByronJohnson> rlpowell: I suspect the issue is not be due to cabal itself, but because GHC is linking different packages because of how your package is configured; it might be a GHC bug worth reporting
05:30:54 <rlpowell> Uh.
05:31:02 <rlpowell> But that "Tidy core" thing is cabal, no?
05:31:42 <donri> that's probably ghc
05:32:02 <rlpowell> Huh.  OK.
05:32:15 <donri> core is ghc's intermediate language
05:32:29 <rlpowell> I'm actually wondering if it's even happstack-authenticate-0.9.8  that's the problem; it could be working on the whole code package at that point.
05:32:45 <rlpowell> It is perhaps worth noting that Main.hs is 1435 lines.
05:33:08 <rlpowell> In the past, running ghc directly has been *much* faster.
05:33:13 <rlpowell> But I can't get it to run right now.
05:33:23 <rlpowell> Main.hs:43:8:
05:33:23 <rlpowell>     Could not find module `Text.RegexPR'
05:33:27 <donri> running ghc directly defaults to no optimization
05:33:31 <donri> cabal install --disable-optimization
05:33:34 <donri> should be faster too
05:33:58 <rlpowell> 04-21:36 <       donri> running ghc directly defaults to no optimization -- Huh. That seems a not-great default.
05:34:10 <donri> yea there's been talk of changing the default
05:34:13 <donri> cabal defaults to -O1
05:34:44 <donri> usually people use cabal when building things where you care about optimization, anyway
05:35:07 <rlpowell> cabal install -v3 --disable-optimization 2>&1  16.78s user 4.10s system 58% cpu 35.555 total
05:35:13 <rlpowell> ^^^ Ah, yes, that's much better, thank you.
05:35:19 <rlpowell> I can have a "make debug" that does that.
05:35:42 <donri> or configure it in ~/.cabal/config
05:35:54 <rlpowell> Well, I don't want to *always* not optimize.
05:35:59 <donri> aye
05:36:02 <rlpowell> If this is a bug worth reporting, I would need to know how to report it.
05:36:17 <rlpowell> i.e. this is *hardly* a minimal test case; what sort of info would people need?
05:36:43 <donri> either http://hackage.haskell.org/trac/ghc/ or https://github.com/haskell/cabal/issues depending on what the problem really is :p
05:36:52 <donri> ah
05:36:55 <donri> yea, don't know :)
05:37:07 <rlpowell> Heh.  'k.
05:38:56 <donri> beware that disabling optimization and forgetting about it can make you run into what seems to be performance problems that'd otherwise get optimized away
05:39:09 <donri> for most code, non-optimized is fast enough. and for some code, it really makes a difference.
05:42:03 <rlpowell> *nod*
05:42:25 <donri> (even with -O1, the scoutess buildbot was killing servers, and -O2 magically fixed it. after days of people debugging it :D)
05:42:40 <rlpowell> It's not the default, so I'm not worried.
05:42:48 <rlpowell> the "make" default is now -O2
05:46:43 <stepkut> success!
05:46:49 <stepkut> I have cat ears now
05:47:16 <stepkut> need to tweak the firmware a bit and do some calibration
05:47:25 <stepkut> but the construction phase is done
05:47:32 <stepkut> next phase is: clean for the party :)
05:47:41 <stepkut> but first, a sleep cycle
05:49:42 <donri> :D