11:35 <Anarchos> opam update took 88minutes .... :/

11:44 <discocaml> <mseri.> It takes less than a minute on my laptop 🤯

11:50 <discocaml> <masterbuilder> same

11:52 <Anarchos> i have the debug output if someone want to tell me what goes wrong

13:16 <discocaml> <sim642> WSL causes significant slowdown of opam (and maybe compilation in general?) if the files are in some directory which maps to the Windows filesystem. At least that's what I've noticed from students using WSL for OCaml

13:17 <Anarchos> sim642 i am on haiku, a unix like system ; not windows.

14:23 <discocaml> <adel> hey guys, can someone simply explain what's going on please?

14:23 <discocaml> <adel> https://cdn.discordapp.com/attachments/436568060288172044/1144638120030117968/closures_in_action.png

15:26 <Leonidas> is there a good way to look up the signal number from close_process? I get -8 and then it tells me to look it up in `Sys` but there is not `int -> string` or anything to get a human readable signal, just all kinds of definitions

15:37 <discocaml> <JM> assuming ocaml is using the standard unix signal numbers, "man signal" would be the best source

15:37 <discocaml> <JM> (on my manchine, that gives me: 8 SIGFPE floating point exception)

15:39 <discocaml> <JM> actually no

15:40 <discocaml> <JM> just check in utop, -8 is Sys.sigpipe

15:40 <discocaml> <JM> not sure if there is a better way than probe the various value in utop 😦

15:52 <Leonidas> That's what I ended up using

15:52 <Leonidas> The manual has them in the same order as the negative numbers decrease, so it was an ok guess

15:55 <discocaml> <barconstruction> what do you mean by this? like all files in wsl are normally stored in a special folder\\wsl$\MyDistro\

15:55 <discocaml> <barconstruction> or is there another way to have wsl connect to windows directories

16:01 <discocaml> <sim642> I don't use Windows so I don't precisely know. But I guess usually WSL terminal opens at `/mnt/c/...` or something, which directly maps to the Windows filesystem. But if you `cd ~` then that's something different, which isn't mounted directly from Windows I guess. At least I think that's what students have done to get opam to create a switch in sane amount of time

16:54 <discocaml> <Ada> wsl runs in a virtual machine with its own ext4 disk image, and mounts windows disks over something unholy which i think might be based on network shares but don’t quote me on that

16:55 <discocaml> <Ada> does the same thing for accessing wsl installs in file explorer, sets up a network drive that exposes the ext4 file system over something horribly slow

16:57 <discocaml> <Ada> appears to be a plan 9 network share

16:57 <discocaml> <Ada> https://cdn.discordapp.com/attachments/436568060288172044/1144677036867203162/image.png

18:37 <discocaml> <Kali> yes, it uses the p9fs protocol

20:47 <discocaml> <cemerick> it's become really frustrating that alcotest raises and prints exceptions on test failures. The search for a sweet-spot test framework continues.

20:49 <discocaml> <jumpnbrownweasel> Is the stack trace the cause of the frustration, or something else?

20:51 <companion_cube> do your own, @cemerick :)

20:51 <companion_cube> (not kidding, test frameworks are a place where there's basically no downside to it)

20:53 <discocaml> <jumpnbrownweasel> Yeah, I have written my own and it isn't difficult. But I'm raising exceptions to indicate test failures. 🙃 That's why I wondered what problems it caused.

20:55 <discocaml> <cemerick> yeah, the same stack trace, all the time, for every failure. It's a bizarre choice.

20:55 <discocaml> <andreypopp> dune's cram are good, no?

20:56 <discocaml> <cemerick> always unrelated to the actual test ofc

20:56 <discocaml> <cemerick> companion_cube: oh, I will; I've written one for almost every lang I've worked in, eventually 🙃

20:56 <discocaml> <cemerick> cram tests have very narrow applicability IME

20:58 <discocaml> <cemerick> the whole test, check, promote workflow has never sat right with me, nevermind that I almost never want to restrict my test data representation to ~plain text

20:58 <discocaml> <jumpnbrownweasel> It's true that the stack trace is often missing the frame you care about. I guess just printing the test name is best.

20:59 <discocaml> <jumpnbrownweasel> I had printed both, but I can see how it is annoying.

20:59 <discocaml> <cemerick> tbc, I'm talking about simple check failures, not when *my* test raises

20:59 <discocaml> <cemerick> so the entire stack trace is useless

20:59 <discocaml> <jumpnbrownweasel> Understood.

20:59 <discocaml> <cemerick> esp since I always ensure my assertions have good messages / expected/actual printers attached

21:00 <discocaml> <cemerick> anyway! </griping>

21:03 <discocaml> <jumpnbrownweasel> As I was working on it I kept hoping that I would find a way to get reliable stack traces, but I never did. It seems to almost randomly miss some frames, I assume due to inlining since there are usually no tail calls.

21:03 <discocaml> <jumpnbrownweasel>

21:03 <discocaml> <jumpnbrownweasel> (You don't need the stack trace anyway for an assertion failure, as you say.)

21:04 <discocaml> <jumpnbrownweasel> A test assertion, I mean.

21:20 <discocaml> <cemerick> just noticed "Jane Street have requested that Eio not use objects." https://github.com/ocaml-multicore/eio/pull/553 😆

21:21 <discocaml> <cemerick> it's always good to know explicitly re: the tail that wags

21:51 <discocaml> <andreypopp> I didn't get the motivation behind this request though.

21:53 <pgiarrusso> 6:57 PM <discocaml> <Ada> https://cdn.discordapp.com/attachments/436568060288172044/1144677036867203162/image.png

21:54 <pgiarrusso> TIL that A: isn't reserved for floppies any more!

22:04 <discocaml> <Et7f3 (@me on reply)> I think it is just the default name like E: for first usb stick if you have two disk

22:05 <discocaml> <Et7f3 (@me on reply)> Even C: we can change but at your own risk since it is hardcoded in many place

22:58 <discocaml> <JM> I'll wait to see what the new API feels like, but I won't miss these object type signatures...

23:01 <discocaml> <cemerick> That's the amusing part; absent further comment, all we can conclude (slightly ungenerously I suppose) is "JS says so"

23:02 <discocaml> <cemerick> One can fret about notation ofc, but row-level polymorphism is great

23:08 <discocaml> <deepspacejohn> I vaguely remember other people unhappy about it using objects before, but I admit I haven’t followed it closely. It would have been nice to see the rationale either way though.

23:17 <discocaml> <JM> OCaml structural typing makes exploring new API difficult for me. All the sudden instead of Merlin/LSP telling me that method x expect an argument of type foo, I'm welcomed by a long list of methods the object passed in must implement.

23:18 <discocaml> <JM> But I keep an open mind, I'll reimplement the 2/3 programs I have written with eio, and maybe I'll be regretting the object based API

23:29 <discocaml> <cemerick> That's fair, the editor tooling isn't tuned for objects as well as for other modalities

23:48 <discocaml> <JM> From what I remember the main points were:

23:48 <discocaml> <JM> * in current OCaml calling methods on objects is slower than an equivalent functional implementation, and nobody is seriously considering improving that. (it's the kind of micro optimisation that might matter to JS)

23:48 <discocaml> <JM> * objects are globally foreign to the usual OCaml dev, most library designers don't use them, most people in the compiler team haven't worked on that part of the compiler, you won't find many resources on how to use them (e.g. even in teaching material, there is an object chapter for completeness, but the focus is elsewhere) so it's weird for a foundational library to switch to objects.

23:54 <discocaml> <regularspatula> Are you talking about cram or expect tests?

23:57 <discocaml> <regularspatula> I use both frequently, so I was curious about this