Newest at the top
2025-10-08 20:04:56 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 240 seconds) |
2025-10-08 20:04:08 +0200 | poscat | (~poscat@user/poscat) poscat |
2025-10-08 20:03:55 +0200 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
2025-10-08 20:03:33 +0200 | tromp | (~textual@2001:1c00:3487:1b00:b551:deec:8ee1:7922) (Ping timeout: 244 seconds) |
2025-10-08 20:03:25 +0200 | poscat | (~poscat@user/poscat) poscat |
2025-10-08 20:03:10 +0200 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
2025-10-08 20:01:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-08 20:00:39 +0200 | poscat | (~poscat@user/poscat) poscat |
2025-10-08 20:00:28 +0200 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
2025-10-08 19:59:40 +0200 | poscat | (~poscat@user/poscat) poscat |
2025-10-08 19:59:30 +0200 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
2025-10-08 19:59:17 +0200 | poscat | (~poscat@user/poscat) poscat |
2025-10-08 19:58:34 +0200 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
2025-10-08 19:57:47 +0200 | <tomsmeding> | *counterexample |
2025-10-08 19:57:41 +0200 | <tomsmeding> | the output of a model checker (which is considered "formal methods") on a counter example is, guess what, a backtrace |
2025-10-08 19:57:12 +0200 | <__monty__> | int-e: That's poetry. |
2025-10-08 19:57:03 +0200 | <EvanR> | and don't care |
2025-10-08 19:56:54 +0200 | <EvanR> | the backtrack workflow in other languages is so powerful that dynamic language programmers write 100s of partial functions per file |
2025-10-08 19:56:54 +0200 | <tomsmeding> | anyhow |
2025-10-08 19:56:52 +0200 | <tomsmeding> | no they're probably not lexical, so I lied to bwe |
2025-10-08 19:56:42 +0200 | <tomsmeding> | or wait is that true? |
2025-10-08 19:56:31 +0200 | <tomsmeding> | lexical ones, even |
2025-10-08 19:56:24 +0200 | <tomsmeding> | requies you to rebuild the world, but then you do get better backtraces |
2025-10-08 19:56:13 +0200 | <tomsmeding> | the new automatic profiling backtraces are nice, though |
2025-10-08 19:55:51 +0200 | <tomsmeding> | (I speak from experience) |
2025-10-08 19:55:39 +0200 | <tomsmeding> | which is sometimes very unhelpful |
2025-10-08 19:55:25 +0200 | <tomsmeding> | well that's what I was saying: it shows you where the naughty instance is, but not how the program got there |
2025-10-08 19:55:02 +0200 | <haskellbridge> | <sm> in a production codebase it's much less likely (because of needing an unbroken chain of HasCallStack I guess) |
2025-10-08 19:54:58 +0200 | <EvanR> | control F and witnessing the proof for every result found would also work |
2025-10-08 19:54:16 +0200 | <haskellbridge> | <sm> tomsmeding: that one was good yes |
2025-10-08 19:54:15 +0200 | <tomsmeding> | chasing false trails in debugging is a demotivating waste of time :p |
2025-10-08 19:53:59 +0200 | <EvanR> | if you have 2 heads, reconsider your ways |
2025-10-08 19:53:56 +0200 | <tomsmeding> | for debugging, yes |
2025-10-08 19:53:42 +0200 | <EvanR> | I guess 2 is spam enough |
2025-10-08 19:53:22 +0200 | <tomsmeding> | EvanR: it doesn't if you have multiple uses of the function |
2025-10-08 19:53:06 +0200 | <tomsmeding> | (: |
2025-10-08 19:53:00 +0200 | <int-e> | tomsmeding: Once upon a time, I had an empty list. It didn't last. |
2025-10-08 19:52:44 +0200 | <tomsmeding> | sm: "last, called at <interactive>:79:1 in interactive:Ghci17" |
2025-10-08 19:52:41 +0200 | <EvanR> | spam |
2025-10-08 19:52:39 +0200 | <EvanR> | assuming you didn't space heads |
2025-10-08 19:52:35 +0200 | <__monty__> | Also makes me more upset about the impartial warnings by default though. |
2025-10-08 19:52:33 +0200 | <EvanR> | control F also works |
2025-10-08 19:52:31 +0200 | <yahb2> | https://paste.tomsmeding.com/dg8lKLH8 |
2025-10-08 19:52:30 +0200 | <tomsmeding> | %% last [] |
2025-10-08 19:52:22 +0200 | <__monty__> | That's good enough for me, so I'm happier now than I was 20 minutes ago. |
2025-10-08 19:52:19 +0200 | <haskellbridge> | <sm> such information is famously elusive in GHC's various back/stack traces |
2025-10-08 19:52:12 +0200 | <tomsmeding> | and if the instance is in some kind of often-utility function, sometimes that still tells you very little |
2025-10-08 19:51:55 +0200 | <tomsmeding> | __monty__: it shows where the naughty instance is, but not how the program got there |
2025-10-08 19:51:49 +0200 | <haskellbridge> | <sm> tomsmeding I think monty was wishing that it would report where the bad partial code is (package, module, line number etc.) |
2025-10-08 19:51:40 +0200 | <__monty__> | So it already shows where the naughty instance is? And we're all just fantasizing that it's hard to pinpoint still? |