00:39 <discocaml> <limp.biskit> ughhh i think something with tcp keepalive is broken in eio

00:39 <discocaml> <limp.biskit> i don't want to think about it

00:39 <discocaml> <limp.biskit> their i/o stack is incredibly impressive, until it's not

00:39 <discocaml> <limp.biskit> 🙂

01:18 <discocaml> <yawaramin> i'm seeing this too with ppxlib, but i don't understand, is it a compilation issue? https://github.com/yawaramin/fun-sql/blob/bd156f9cf71b10b51f09bc8c4d9088dedb65a44f/test_ppx/test.expected.ml#L8

01:33 <discocaml> <anmonteiro> this is done on purpose to avoid unused type warnings

01:34 <discocaml> <anmonteiro> this is done on purpose to avoid unused type/value warnings

03:09 <discocaml> <yawaramin> oh...but why would we not want unused warnings? eg above i want to use the type `t` and value `ret`. if i didn't, it's a mistake...

05:31 <discocaml> <sim642> Maybe because some derivers generate a bunch of different things, not all of whom you might actually use

06:32 <discocaml> <sim642> Although could also use attributes to suppress the warning locally

06:32 <discocaml> <sim642> And I have no idea about the first ignored unit function

06:46 <discocaml> <anmonteiro> it uses the type `(_: t)`

06:53 <discocaml> <sim642> But the type is created by the user not the deriver, so if the type is unused then the user might want to know. Or if the derived function needs it, the annotation could just be included there

08:49 <discocaml> <darrenldl> you checked with wireshark about the tcp traffic?

13:07 <discocaml> <getzapped.> Is there any config option to stop ocamlformat from wrapping larger match arm bodies in parentheses? I type this:

13:07 <discocaml> <getzapped.> ```ocaml

13:07 <discocaml> <getzapped.> | Some num ->

13:07 <discocaml> <getzapped.> match Grid.drop ~grid ~col:num ~player:grid.current with

13:07 <discocaml> <getzapped.> | Some g -> main_loop ~grid:(Grid.switch g)

13:07 <discocaml> <getzapped.> | None ->

13:07 <discocaml> <getzapped.> print_endline "Something went wrong";

13:07 <discocaml> <getzapped.> main_loop ~grid

13:07 <discocaml> <getzapped.> ```

13:07 <discocaml> <getzapped.> and the formatter turns it into this

13:07 <discocaml> <getzapped.> ```ocaml

13:07 <discocaml> <getzapped.> | Some num -> (

13:08 <discocaml> <getzapped.> match Grid.drop ~grid ~col:num ~player:grid.current with

13:08 <discocaml> <getzapped.> | Some g -> main_loop ~grid:(Grid.switch g)

13:08 <discocaml> <getzapped.> | None ->

13:08 <discocaml> <getzapped.> print_endline "Something went wrong";

13:08 <discocaml> <getzapped.> main_loop ~grid)

13:08 <discocaml> <getzapped.> ```

13:54 <discocaml> <otini_> I don’t know, but I prefer to always parenthesize (or put in a `let ... in` due to the ambiguity of the syntax.

13:54 <discocaml> <otini_> I don’t know, but personally I prefer to always parenthesize (or put in a `let ... in`) due to the ambiguity of the syntax.

14:01 <discocaml> <deepspacejohn> Yeah. I realize this doesn't answer the question, but IMO it's best to use `( )`/`begin end`/`let in` anyway because otherwise the syntax is ambiguous.

14:31 <palainp> §1

14:31 <palainp> oups

14:48 <discocaml> <limp.biskit> for now i am just gonna leave it and debug later

14:48 <discocaml> <limp.biskit> i'm on wsl2 so i'm not sure how i'd even capture packets. i think their stack uses uring as well so i can't rule out kernel version weirdness

14:55 <discocaml> <getzapped.> i can live with begin end, but the formatter still turns begin into ( and end into ) in this case. is there something i can do to make it not?

14:59 <discocaml> <deepspacejohn> `exp-grouping=preserve` https://ocaml.org/p/ocamlformat/latest/doc/manpage_ocamlformat.html

15:03 <discocaml> <deepspacejohn> You can also use this to experiment with different configurations https://ahrefs.github.io/ocamlformat/

16:10 <discocaml> <yawaramin> true, some might. but i don't think ppx_deriving_yojson does? it just generates `of_yojson` or `to_yojson` or similar functions depending on the exact deriving syntax you used. eg you can generate _only_ a serializer by just doing `[@@deriving to_yojson]`. but sure, maybe ppxlib is doing this out of 'an abundance of caution'. the utility is arguable, though, i think.