2025/10/08

Newest at the top

2025-10-08 20:04:56 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 240 seconds)
2025-10-08 20:04:08 +0200poscat(~poscat@user/poscat) poscat
2025-10-08 20:03:55 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-10-08 20:03:33 +0200tromp(~textual@2001:1c00:3487:1b00:b551:deec:8ee1:7922) (Ping timeout: 244 seconds)
2025-10-08 20:03:25 +0200poscat(~poscat@user/poscat) poscat
2025-10-08 20:03:10 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-10-08 20:01:04 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-10-08 20:00:39 +0200poscat(~poscat@user/poscat) poscat
2025-10-08 20:00:28 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-10-08 19:59:40 +0200poscat(~poscat@user/poscat) poscat
2025-10-08 19:59:30 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-10-08 19:59:17 +0200poscat(~poscat@user/poscat) poscat
2025-10-08 19:58:34 +0200poscat(~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?