13:58 <discocaml> <aantron> ``` Type [> `Dir ] is not compatible with type

13:58 <discocaml> <aantron> [> Eio.Fs.dir_ty ] = [> `Dir ]```

13:58 <discocaml> <aantron> What

14:00 <discocaml> <aantron> I suppose that's due to the row type variables being different

14:19 <discocaml> <leviroth> That looks vaguely familiar. Possibly the compiler is saying something misleading here.

14:23 <discocaml> <limp.biskit> eio’s use of polymorphic typing is rather wacky

14:41 <discocaml> <limp.biskit> not sure if it’s better or worse than everything being a class

15:14 <companion_cube> Probably way worse

15:14 <companion_cube> Since objects were the perfect fit for the particular problem

16:41 <discocaml> <froyo> Jane Street have requested that Eio not use objects

16:45 <companion_cube> Yep yep

17:54 <discocaml> <yawaramin> Jane Street objected

17:54 <companion_cube> it was a `class` struggle

18:04 <discocaml> <yawaramin> they wanted a different method

18:14 <dh`> we inherit the mess

18:14 <companion_cube> for the Eio team, this order was a late binding

18:14 <companion_cube> but they got the message

18:15 <discocaml> <limp.biskit> and jane street is on board with capabilities?

18:16 <companion_cube> good question :D

18:16 <companion_cube> maybe they just don't want any major contender to use features (objects) that they don't like

18:20 <discocaml> <limp.biskit> i’ve never understood it. seems like it would be a better choice to improve the perceived shortcomings in objects

18:21 <companion_cube> I think it's partly because their devs don't know/use objects

18:21 <companion_cube> but perhaps also their fork of OCaml supports them badly? or it's in the way??

18:22 <discocaml> <limp.biskit> i didn’t know they forked ocaml?

18:22 <companion_cube> well they have their compiler with experimental features

18:22 <companion_cube> flambda2, modes, etc.

18:22 <discocaml> <limp.biskit> ah

18:22 <discocaml> <limp.biskit> i wouldn’t be shocked

18:23 <discocaml> <limp.biskit> the object system does seem rather neglected and still has overhead issues that shouldn’t be there in a multi pass compiler

20:08 <discocaml> <leviroth> What's the least painful way to build a specific version of the ocamlformat executable? I want to get a version that matches the one used in someone's GitHub project, but ideally I would not have to change the state of my current switch or install a new one. Basically I would like to temporarily clone the dependencies somewhere and then run a dune build.

20:23 <discocaml> <anmonteiro> least painful? probably something like `nix shell nixpkgs#ocamlPackages.ocamlformat_0_23_0` (replace with your version from the ones available here <https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/ocaml-packages.nix#L1306-L1316>)

20:23 <discocaml> <anmonteiro> least painful? probably something like `nix shell nixpkgs#ocamlPackages.ocamlformat_0_23_0 -c $SHELL` (replace with your version from the ones available here <https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/ocaml-packages.nix#L1306-L1316>)

23:39 <discocaml> <leviroth> Ah interesting. Never having used nix before, should that generally work out of the box if I install nix from my system package manager?

23:40 <discocaml> <anmonteiro> I think so

23:40 <discocaml> <anmonteiro> at most you may have to add `extra-experimental-features = nix-command flakes` to your `~/.config/nix/nix.conf`