01:22 <companion_cube> another day, another flash of anger at Buffer.t

01:22 <companion_cube> I should keep a count somewhere

01:37 <discocaml> <coolccat> Hi, is there any way I can wrap a string/buffer in an in_channel for unit testing?

01:38 <discocaml> <coolccat> I have a function that reads from an in_channel I want to test

01:39 <discocaml> <coolccat> Does a temporary file work maybe? Just create a temp file which contains the string and read from that + delete?

01:39 <discocaml> <coolccat> Hoping for an easier way though

01:41 <discocaml> <hockletock> https://ocaml.org/play#code=bGV0IGljX29mX3N0cmluZyBzID0KICBsZXQgcGlwaW4sIHBpcG91dCA9IFVuaXgucGlwZSAoKSBpbgogIGxldCBvYyA9IFVuaXgub3V0X2NoYW5uZWxfb2ZfZGVzY3IgcGlwb3V0IGluCiAgT3V0X2NoYW5uZWwub3V0cHV0X3N0cmluZyBvYyBzOwogIE91dF9jaGFubmVsLmNsb3NlIG9jOwogIFVuaXguaW5fY2hhbm5lbF9vZl9kZXNjciBwaXBpbgo%3D

01:41 <discocaml> <hockletock> that's what I used for that purpose in advent of code

01:47 <discocaml> <coolccat> thx!

02:02 <companion_cube> ahaha no you can't

08:09 <reynir> @hockletock I think you're in trouble if the write to the pipe blocks...

09:20 <discocaml> <ada2k> are there any proposals for an exn_bt type in stdlib?

09:23 <discocaml> <ada2k> i know picos has one, but stdlib domains also encounter the need for one: https://github.com/ocaml/ocaml/issues/12362#issuecomment-2214051633. having a shared type (even if it's just an alias for a tuple) would be good

10:27 <discocaml> <lukstafi> Somehow I missed the immutable arrays PR till it's been brought up on Discuss just now: https://github.com/ocaml/ocaml/pull/13097 . A bit strange that it doesn't mention the option to call them "tuples"? "immutable array" is a mouthful compared to "tuple".

10:55 <discocaml> <sim642> Tuple would be way more confusing, because existing tuples in OCaml have statically known length, but immutable arrays would not

11:29 <discocaml> <lukstafi> But the tuple family of types exist only in the metalanguage, not in OCaml 😉

11:29 <discocaml> <lukstafi> In OCaml there are only pairs, triples, quadruples...

11:31 <discocaml> <lukstafi> In fact it's more about the pragmatic choice allowing freezing of arrays into immutable arrays. Instead, you could have the option of no-copy injecting pairs, triples, quadruples... into the new types.

11:32 <discocaml> <lukstafi> *into the new (parametric) type

12:27 <discocaml> <drupyog> @lukstafi Good luck explaining to beginners (and not beginners) that a "triple" is not a "tuple" 😄

12:28 <discocaml> <drupyog> @lukstafi Good luck explaining to beginners (and not beginners) that a "triple" is not a "tuple" (with your definition) 😄

12:41 <companion_cube> But tuples are heterogeneous

12:41 <companion_cube> No relation to immutable arrays at all

12:44 <discocaml> <lukstafi> Right, homogeneous tuples.

12:48 <octachron> If tuple types were a true type familly, an immutable array could be written as "'elt immutable_array = ('elt * 'all) as 'all"

12:50 <companion_cube> Really i wish people would focus on more important stuff than immutable arrays

13:00 <discocaml> <lukstafi> Because lists are good enough?

13:10 <discocaml> <deepspacejohn> Personally, I think user-implemented immutable arrays are good enough for the times when they're useful

13:13 <companion_cube> Arrays are good enough