02:10 <discocaml> <restrictedchoice> any thoughts on a new channel for oxcaml?

02:20 <companion_cube> if you want even less traffic than here… :D

02:37 <discocaml> <yawaramin> there's a #rocq channel so an OxCaml channel seems reasonable to me

02:43 <companion_cube> oh yeah, sorry, on discord

08:23 <olle> Anyone know anything about first-class function _calls_?

08:23 <olle> Or, in OOP parleur, first-class message passing.

09:51 <discocaml> <kayceesrk> There is an #oxcaml channel now. Thanks for creating this channel.

11:59 <discocaml> <aguluman> I have OxCaml installed. 🥂🫂🐫🧡

14:41 <olle> Would some 0xcaml stuff be merged into core? is there a roadmap or plan?

14:41 <olle> Oxcaml perhaps

14:42 <companion_cube> yes, it's supposed to eventually be all upstreamed

14:42 <companion_cube> if the core team accepts

14:44 <olle> companion_cube: neat! pretty impressive package they made.

14:45 <discocaml> <deepspacejohn> Some of it is already being merged, some of the "miscellaneous extensions"

14:48 <olle> Kewl

15:43 <discocaml> <lukstafi> I've started using agentic LLMs / Cursor and the expect-test harness is a pain for them. To be honest it's also not pleasant for debugging for me. I'll probably keep the tests I have but the new tests gonna be the single-executable `with-stdout-to` then `diff output.expected` idiom.

15:45 <dh`> what would first-class function calls even be?

15:45 <discocaml> <lukstafi> (By single-executable I mean one executable per a not-too-broad set of tests, sorry for confusion. Unlike the big library with all the tests.)

15:45 <discocaml> <deepspacejohn> My personal preference for a long time has been the Dune-style stdout `.expected` tests too. Other options always end up being more trouble than they're worth.

15:46 <discocaml> <deepspacejohn> or cram tests (which are basically the same principle) when I want to test a whole program.

15:48 <discocaml> <lukstafi> The appeal of expect-test is that they are supposed to work as tutorials, poor-man's Jupyter notebooks.

15:54 <discocaml> <yawaramin> i'm doing this too, works well for me. dune has special support for this so you don't even need explicit rules any more. see https://dev.to/yawaramin/bare-bones-unit-testing-in-ocaml-with-dune-1lkb

16:16 <discocaml> <undu> They are called cram tests. They're really useful as regression tests for CLI tools. Although I've used them with dune rules to specify what package are they attached to

16:18 <discocaml> <yawaramin> cram tests are actually slightly different from what i described, see https://dune.readthedocs.io/en/stable/tests.html#cram-tests

16:18 <discocaml> <deepspacejohn> Cram tests are very nice too, though.

16:18 <discocaml> <yawaramin> eg in my tests i don't need `(cram enable)`

16:19 <discocaml> <deepspacejohn> Cram tests also have the advantage of forcing you to make a good CLI

16:20 <discocaml> <yawaramin> right they are meant for testing CLIs; dune's built-in 'bare-bones' diffing can be even if your project is not a CLI

16:39 <discocaml> <undu> ahh, I see how they're different, nice, I didn't know about these

16:40 <discocaml> <undu> does it have tools to be able to filter output? (like timestamps or current working dir)

16:42 <discocaml> <yawaramin> not really...the output has to be exactly the same as the expected file every time to pass the test

16:42 <discocaml> <lukstafi> Do you get a per-file executable with just one `test` rule, or only with one `(test (modules file.ml))` rule per `file.ml`?

16:42 <discocaml> <yawaramin> i always do one directory per test executable

16:44 <discocaml> <lukstafi> Right... That feels heavier... But it does seem like an unjustified feeling.

16:46 <discocaml> <yawaramin> actually, i'm wrong. i'm also using `(modules ...)` to have multiple test executables. see https://github.com/yawaramin/dream-html/blob/main/test/dune

17:01 <discocaml> <deepspacejohn> Hopefully when one of the associated PRs here gets merged, we'll have an automatic alias for each test https://github.com/ocaml/dune/issues/10239

19:36 <discocaml> <lukstafi> Yes, you can already do `dune exec` on these test stanza files, but it's just a part of what `dune test` does.