Search Haskell Channel Logs

Sunday, January 29, 2017

#haskell channel featuring MarcelineVQ, lambdabot, g256, grdvnl`, ertes, ph88,

ph88_ 2017-01-29 05:45:11
ertes, i started ghc with -Rghc-timing to see how much GC is being done, now i get messages such as: <> do you know what the first few things tell me ?
g256 2017-01-29 05:46:18
@system
lambdabot 2017-01-29 05:46:19
Unknown command, try @list
g256 2017-01-29 05:46:38
@version
lambdabot 2017-01-29 05:46:38
lambdabot 5.1
lambdabot 2017-01-29 05:46:39
git clone https://github.com/lambdabot/lambdabot
hpc 2017-01-29 05:46:48
iirc, the first number is the sum of all allocations, and the next number/number is how much you ever ended up actually using at once
ertes 2017-01-29 05:47:02
ph88_: residency is heap usage (the amount of memory actually used at a point in time)
ertes 2017-01-29 05:47:18
the rest i could only guess, so better read the GHC manual on that
g256 2017-01-29 05:47:48
@dice
lambdabot 2017-01-29 05:47:48
unexpected end of input: expecting number, "d" or "("
ertes 2017-01-29 05:47:56
g256: you can use lambdabot in private
ertes 2017-01-29 05:47:59
/query lambdabot
g256 2017-01-29 05:48:07
oh sorry :)
g256 2017-01-29 05:48:13
will do :)
ertes 2017-01-29 05:48:16
no worries =)
MarcelineVQ 2017-01-29 05:49:30
ph88_, ertes: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html#rts-options-to-produce-runtime-statistics
g256 2017-01-29 05:49:49
didn't think that it's visible for everybody :))
ertes 2017-01-29 05:50:40
g256: if you type the command i just gave you, then a new window/tab/whatever will pop up, and everything there is between you and lambdabot =)
ertes 2017-01-29 05:51:00
(and int-e and a few server operators, too)
g256 2017-01-29 05:51:42
ertes: cheers :)
ph88_ 2017-01-29 05:54:39
ertes, thx :)
ph88_ 2017-01-29 05:54:44
MarcelineVQ, ah excellent good find
soniaa 2017-01-29 06:00:00
www.icq-net.eu chat for all people !!!
ph88 2017-01-29 06:04:36
when i have a top-level function that never gets called through main, will it be optimized away when i do a regular build (outside of ghci) ?
kirillow 2017-01-29 06:07:20
how do i ignore an exception and keep the programm running
ertes 2017-01-29 06:09:56
ph88: likely, unless you're building a library, although i'm not sure if the linker is very aggressive at eliminating dead code
ertes 2017-01-29 06:10:01
kirillow: catch it
ertes 2017-01-29 06:10:27
kirillow: but in that case you should only ignore certain exceptions
ertes 2017-01-29 06:10:49
kirillow: https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-Exception.html#v:catchJust
kirillow 2017-01-29 06:11:57
ertes: but isnt that what your function did?
kirillow 2017-01-29 06:12:12
ertes: it still timed out?
kirillow 2017-01-29 06:13:02
i mean catching exceptions, not ignoring only specific ones
ertes 2017-01-29 06:13:07
kirillow: mine rethrows the exception… it's only for seeing the exception… my guess is that your websockets library has a catch-all handler that does nothing, but did you actually verify that something like a timeout is happening?
ertes 2017-01-29 06:13:37
kirillow: ignoring exceptions is highly risky
kirillow 2017-01-29 06:14:45
Uhm, sorry, I can't follow you. It said "Thread killed by Warp's timeout reaper" and I was inable to send more messages. Isn't that verified then?
ertes 2017-01-29 06:16:46
i don't know
ertes 2017-01-29 06:17:05
that sounds more like warp is killing your handler, because it didn't return for a long time
ertes 2017-01-29 06:17:19
not because there was a network timeout
ertes 2017-01-29 06:20:00
the way this seems to work is: warp receives the request, the websockets middleware recognises it as a websockets request and calls your websockets handler… while that one is running, warp waits for it to finish and kills it after a certain amount of time
ertes 2017-01-29 06:20:49
if that's the case, warp has no way of knowing whether the handler is just doing its work or is actually hanging… i imagine that you're supposed to disable timeouts for websockets handlers
kirillow 2017-01-29 06:21:17
hm yes
ertes 2017-01-29 06:21:36
that timeout kill might actually be the reason why you get the behaviour you observed
grdvnl` 2017-01-29 06:25:20
:help
grdvnl` 2017-01-29 06:25:27
exit