06:12 <d_bot> <Bluddy> yep. the less we have to think about this stuff, the better

06:12 <d_bot> <Bluddy> make it all opinionated and be done with it

06:27 <d_bot> <Bluddy> companion_cube: I take back my taking back of the question above. CCRandom (wisely, IMO) overrides the default Random functions to all take state. But then you need to store that state somewhere (usually in your state record), and that makes the record unserializable except with Marshal.

07:50 <greenbagels> opam update 23.59s user 19.40s system 7% cpu 9:39.67 total

07:51 <greenbagels> i *really* need to remember to enable the debug flags more often

07:51 <greenbagels> a 10 minute opam update...

15:06 <d_bot> <VPhantom> I just spent a while adding printfs everywhere to find where a program raised `Not_found`. This is despite Dune compiling with `-g` and my running with `OCAMLRUNPARAM=b` which did yield a 2-line backtrace, but unrelated to where the problem turned out to be. What could be the cause for `Printexc.get_backtrace` within an exception handler not to return a complete stack?

15:07 <companion_cube> you absolutely need to call it first thing

15:07 <companion_cube> with e -> let bt = Printexc.get_backtrace () in …

15:07 <companion_cube> otherwise it might be erased

15:08 <d_bot> <VPhantom> I use it left of a `^` operator… 🤔

15:08 <d_bot> <VPhantom> I'll refactor with a binding to be sure.

15:09 <d_bot> <VPhantom> Well I'll be damned. 😛

15:09 <companion_cube> yeah, be super careful with that

15:10 <d_bot> <VPhantom> First really means dead first.

15:10 <companion_cube> yeah, cause calling another function might kill your frame

15:10 <d_bot> <VPhantom> Welp, now I can remove my 30-ish prints to stderr. 😛

15:11 <d_bot> <VPhantom> (That was a heck of a throw-back to my old C-without-gdb days.)

15:11 <companion_cube> \o/

15:11 <companion_cube> well ppx_deriving.show is worth it even just for printf-debugging, in my experience

15:11 <companion_cube> (and I do a lot of that)

15:11 <d_bot> <VPhantom> Indeed. I haven't taken the plunge yet but it's on my radar.

15:12 <companion_cube> sad it's not standard, but it's just so useful

16:52 <d_bot> <mbacarella> does the tooling go out of its way to hide names with `__` in them?

16:53 <d_bot> <mbacarella> maybe just module names?

16:53 <companion_cube> cause they're used by dune for wrapped libraries I think

16:56 <d_bot> <koche> hello, can anyone help me with threads in OCaml?

16:58 <d_bot> <mbacarella> right. is this __ hiding documented somewhere?

16:58 <d_bot> <octachron> It is the reverse `__` was used for type paths that ought to be hidden before dune.

16:58 <companion_cube> @koche you can always ask

17:00 <d_bot> <koche> i have a syntax error here and don't know how to fix it

17:00 <d_bot> <koche> https://cdn.discordapp.com/attachments/436568060288172044/987038848490020935/unknown.png

17:00 <d_bot> <octachron> https://v2.ocaml.org/manual/comp.html: `-short-paths`

17:00 <d_bot> <octachron> You cannot use directives outside of the toplevel/REPL.

17:56 <d_bot> <mbacarella> > -short-paths

17:56 <d_bot> <mbacarella> > When a type is visible under several module-paths, use the shortest one when printing the type’s name in inferred interfaces and error and warning messages. Identifier names starting with an underscore _ or containing double underscores __ incur a penalty of +10 when computing their length.

17:56 <d_bot> <mbacarella> ah, thanks