Newest at the top
2024-12-25 15:23:05 +0100 | meritamen | (~meritamen@user/meritamen) (Remote host closed the connection) |
2024-12-25 15:18:33 +0100 | Pixi | (~Pixi@user/pixi) (Ping timeout: 244 seconds) |
2024-12-25 15:14:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
2024-12-25 15:14:38 +0100 | <int-e> | neither of those is a generic logging mechanism |
2024-12-25 15:14:34 +0100 | meritamen | (~meritamen@user/meritamen) meritamen |
2024-12-25 15:14:11 +0100 | <int-e> | There's two parts of Debug.Trace; the `traceEvent` family of functions is subject to the event log being enabled during linking. The other functions unconditionally write to the program's output (stderr), and meant to be used in a build-run-edit debugging loop |
2024-12-25 15:13:02 +0100 | meritamen | (~meritamen@user/meritamen) (Remote host closed the connection) |
2024-12-25 15:12:47 +0100 | meritamen | (~meritamen@user/meritamen) meritamen |
2024-12-25 15:11:08 +0100 | EvanR | (~EvanR@user/evanr) (Quit: Leaving) |
2024-12-25 15:10:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-25 15:09:37 +0100 | <int-e> | hellwolf: "it"? |
2024-12-25 15:09:17 +0100 | meritamen | (~meritamen@user/meritamen) (Remote host closed the connection) |
2024-12-25 15:05:54 +0100 | gentauro | (~gentauro@user/gentauro) gentauro |
2024-12-25 15:05:10 +0100 | meritamen | (~meritamen@user/meritamen) meritamen |
2024-12-25 15:03:35 +0100 | meritamen | (~meritamen@user/meritamen) (Remote host closed the connection) |
2024-12-25 15:01:34 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
2024-12-25 14:58:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-12-25 14:57:35 +0100 | <hellwolf> | can you turn it off by environment variable or RTS options? |
2024-12-25 14:56:45 +0100 | <int-e> | Debug.Trace goes a long way. |
2024-12-25 14:56:21 +0100 | <hellwolf> | fwiw, I currently do Text.IO and print out result as much it can, and it stops at where it crashed. That's actually always helpful... good old printf debugging, I guess. |
2024-12-25 14:56:16 +0100 | int-e | shrugs |
2024-12-25 14:56:09 +0100 | <int-e> | so that tells you where f was called from. |
2024-12-25 14:55:55 +0100 | <yahb2> | [("f",SrcLoc {srcLocPackage = "interactive", srcLocModule = "Ghci7", srcLocFile = "<interactive>", srcLocStartLine = 41, srcLocStartCol = 81, srcLocEndLine = 41, srcLocEndCol = 82})] |
2024-12-25 14:55:55 +0100 | <int-e> | % let f :: HasCallStack => String; f = show (getCallStack ?callStack) in putStrLn f |
2024-12-25 14:55:51 +0100 | <yahb2> | <no output> |
2024-12-25 14:55:51 +0100 | <int-e> | % :set -XImplicitParams |
2024-12-25 14:55:30 +0100 | <yahb2> | <interactive>:37:57: error: [GHC-88464] ; Variable not in scope: ; (?) :: (CallStack -> [([Char], SrcLoc)]) -> CallStack -> a0 |
2024-12-25 14:55:30 +0100 | <int-e> | % let f :: HasCallStack => String; f = show (getCallStack ?callStack) in putStrLn f |
2024-12-25 14:55:09 +0100 | <yahb2> | <no output> |
2024-12-25 14:55:09 +0100 | <int-e> | % import GHC.Stack |
2024-12-25 14:55:00 +0100 | <yahb2> | <no location info>: error: [GHC-35235] ; Could not find module ‘GHC.CallStack’. ; It is not a module in the current program, or in any known package. |
2024-12-25 14:54:59 +0100 | <int-e> | % import GHC.CallStack |
2024-12-25 14:53:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-25 14:52:45 +0100 | Nixkernal | (~Nixkernal@90.74.198.178.dynamic.cust.swisscom.net) Nixkernal |
2024-12-25 14:51:16 +0100 | <hellwolf> | what should I use instead, I have "gen_assert_msg" helper I use in a few places, it uses "error" inside. but it definitely does not produce the stack trace. I am not sure I should pursue such a stack trace, I am all ears on any more sensible debugging strategy. |
2024-12-25 14:49:50 +0100 | <int-e> | But AIUI this can be a good tool to answer the question where a failing function was called from. |
2024-12-25 14:48:46 +0100 | <int-e> | If you'd use that indiscriminately then your program would fill up your memory with complete traces of your computation very quickly. |
2024-12-25 14:47:39 +0100 | <int-e> | It's a call stack; for functions with HasCallStack, the compiler adds code to track them and pass that information on to callees that also have a HasCallStack constraint. |
2024-12-25 14:45:50 +0100 | <yahb2> | error :: GHC.Internal.Stack.Types.HasCallStack => [Char] -> a |
2024-12-25 14:45:50 +0100 | <int-e> | % :t error |
2024-12-25 14:45:21 +0100 | <hellwolf> | I read somewhere that I really shouldn't use HasCallStack, what's that all about? |
2024-12-25 14:44:44 +0100 | forell | (~forell@user/forell) forell |
2024-12-25 14:43:02 +0100 | meritamen | (~meritamen@user/meritamen) meritamen |
2024-12-25 14:40:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-12-25 14:36:31 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
2024-12-25 14:36:18 +0100 | ash3en | (~Thunderbi@p200300ef0f04dc00f0cbb9f6013f5f8e.dip0.t-ipconnect.de) (Quit: ash3en) |
2024-12-25 14:35:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-25 14:32:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-12-25 14:32:29 +0100 | meritamen | (~meritamen@user/meritamen) (Client Quit) |
2024-12-25 14:31:45 +0100 | forell | (~forell@user/forell) (Ping timeout: 244 seconds) |