02:56 <discocaml> <contextfreebeer> that's cool! I will definitely keep my eye on this. re2c is not my favorite lexer generator to be honest, but I would definitely consider using it over what we have now

09:16 <discocaml> <fabric.input_output> wish `Core.Bytes` had `[read/write]_[value_type]_[be/le/ne]` functions like `Stdlib.Bytes`

15:57 <discocaml> <pmetzger> I used to have a low opinion of it because of how messy it seemed to be. I completely changed my mind after using it on a few projects. The way it lets you deal with the state machine is nearly unique and (I have now decided) really important for production work. Also, re2c has had serious algorithmic improvements in how things like submatch handling are done that are also impressive.

20:05 <discocaml> <fabric.input_output> is `In_channel` like `io.Reader` in golang?

20:14 <discocaml> <fabric.input_output> ok nvm it isn't, `In_channel.t` is more like `FILE*` in C

20:17 <discocaml> <fabric.input_output> what's an `io.Reader` equivalent though

20:18 <companion_cube> There's not really an established one

20:18 <companion_cube> And that makes me very sad

20:19 <discocaml> <fabric.input_output> 😭

20:22 <discocaml> <fabric.input_output> is there any workaround?

20:46 <dh`> what is an io.Reader?

20:50 <discocaml> <fabric.input_output> https://pkg.go.dev/io#Reader

20:50 <discocaml> <fabric.input_output> you see this as `std::istream` in c++

20:52 <discocaml> <fabric.input_output> or `std::io::Read` in rust

21:01 <discocaml> <fabric.input_output> and probably `Read` in haskell or something

21:01 <dh`> std::istream is the same as a FILE* so I don't understand

21:02 <discocaml> <fabric.input_output> no, `std::fstream` is more like `FILE *`

21:02 <discocaml> <fabric.input_output> `std::istream` is some sort of abstract class that defines an interface for reading values and data from some source

21:04 <dh`> what, like https://man.netbsd.org/funopen.3 :-)

21:04 <dh`> (there's a slightly different version in linux too)

21:04 <dh`> but I take your point

21:04 <dh`> there is no such thing in the ocaml stdlib

21:07 <discocaml> <fabric.input_output> I guess I'll have to make my own "struct o' functions" thingy

21:08 <discocaml> <fabric.input_output> or use a lib

21:09 <discocaml> <bluddy5> companion_cube is working on iostream https://github.com/c-cube/ocaml-iostream

21:09 <discocaml> <bluddy5> but I don't know if it's stable enough from his perspective yet

21:10 <companion_cube> dh`: FILE is not extensible

21:10 <companion_cube> Well I just released iostream 0.2

21:10 <discocaml> <bluddy5> have you benchmarked the performance?

21:11 <companion_cube> Not particularly, but the most important thing is buffering anyway

21:11 <companion_cube> It's objects now

21:12 <companion_cube> And that does improve the API a lot

21:12 <discocaml> <bluddy5> buffering bypasses the method calls?

21:13 <companion_cube> Sure, once you have refilled the buffer you can use it

21:13 <discocaml> <fabric.input_output> would be good to have a `read_byte` or `read_char` function in `In`, I'll have to make a temp 1 byte long buffer and read into that

21:14 <discocaml> <fabric.input_output> would be good to have a `read_byte` or `read_char` function in `In`, I'll have to make a temp 1 byte long bytes object and read into that

21:14 <companion_cube> If you're looking at iostream, what you want is In_buf.t

21:14 <companion_cube> Cause that's what buffering is for

21:16 <discocaml> <fabric.input_output> do I have to `to_seq -> get 1 char from seq -> from_seq`?

21:16 <discocaml> <fabric.input_output> cuz there's still no `read_char` or `read_byte` function

21:20 <companion_cube> Oh yeah, right. I have it in another project. But you can use fill_buf and read the first char from there

21:20 <companion_cube> And then consume it

21:22 <discocaml> <fabric.input_output> is the slice a view or a copy?

21:22 <discocaml> <fabric.input_output> or is it just the entire buffer

21:22 <companion_cube> The slice is the internal buffer

21:22 <companion_cube> There's no implicit copy

21:23 <companion_cube> (it's inspired by rust's BufReader)

21:27 <discocaml> <fabric.input_output> I'm still a beginner in ocaml, so I have a question: I can create my own specialized types and functions that work like `In_buf` because the things are defined with `class` and `class` works kinda like in haskell, or like a trait in rust or an interface in a few other languages?

21:29 <discocaml> <fabric.input_output> because for example I might need to have a `In_buf.t` thingy that reads from a network or something else

21:29 <discocaml> <Kali> classes are functions that produce objects (subtypeable structs, essentially); you're probably looking for modules (which have the implementation/interface duality you're talking about)

21:31 <discocaml> <Kali> classes can't hide information about types, but modules can

21:31 <discocaml> <Kali> they also have better performance

21:33 <discocaml> <Kali> classes are sometimes necessary of course, or they wouldn't exist, but for code organization you want moduels

21:33 <discocaml> <Kali> * modules

21:33 <discocaml> <fabric.input_output> I mean, I'll have to do something like this

21:33 <discocaml> <fabric.input_output> ```haskell

21:33 <discocaml> <fabric.input_output> decode :: (Read reader) => reader -> thing

21:33 <discocaml> <fabric.input_output> ```

21:33 <discocaml> <fabric.input_output> or

21:33 <discocaml> <fabric.input_output> ```rust

21:34 <discocaml> <fabric.input_output> fn decode<Reader: std::io::Read>(reader: &mut Reader) -> Thing { ... }

21:34 <discocaml> <fabric.input_output> ```

21:34 <discocaml> <._null._> Don't post messages with newlines in this channel, the bridge to IRC doesn't like them

21:34 <discocaml> <fabric.input_output> lol

21:35 <discocaml> <fabric.input_output> ok

21:35 <discocaml> <Kali> perhaps move to #beginners?

21:38 <companion_cube> You can easily make instances of In_buf.t

21:38 <companion_cube> Either with an object literal (`object... end`) or a class

21:38 <discocaml> <fabric.input_output> I mean, since it's `class type` I can make specialized instances of it right?

21:39 <companion_cube> Yep

21:39 <discocaml> <fabric.input_output> ok thanks

21:39 <companion_cube> For example I make new ones in iostream-camlzip

21:39 <companion_cube> As a useful example of stream transformations

21:40 <companion_cube> With the stdlib's channels you literally cannot make a (de)compressed in_channel :(

21:40 <discocaml> <fabric.input_output> tbh all I wanted for now was an `in_channel` that reads from a `string` or `bytes`

21:44 <companion_cube> Yep

21:44 <companion_cube> 🤷

21:49 <discocaml> <bluddy5> This is one of those things that isn't so simple to do in ocaml. You basically need to use objects to make it a good experience, but ocaml programmers don't like using its objects very much.

21:49 <discocaml> <Kali> a little funny, given it's in the name

21:50 <discocaml> <bluddy5> yep

21:51 <discocaml> <bluddy5> there are a bunch of other possible ways, but none of them is as clean as just using objects, which is why none of them has been adopted by the stdlib

21:54 <companion_cube> Idk why none has been adopted by the stdlib. My impression is that the core maintainers don't care that much about IO really

21:54 <companion_cube> (which is weird because Xavier has at least one library with a similar OO abstraction)

22:38 <discocaml> <idontwantausernamefeckoff> still a pet peeve of mine that the only thing Eio took feedback on was abstracting away objects because jane street are allergic to hashtags

22:38 <discocaml> <idontwantausernamefeckoff> *the hash key

22:52 <discocaml> <ulugbek3209> A dune build produces a file at `_build/default/src/vscode_ocaml_platform.bc.js` but I need it at `dist/vscode_ocaml_platform.bc.js` . How can I make dune to either output directly the output js file to `dist/` or copy the produced file afterwards?

23:11 <companion_cube> ahah right?

23:22 <discocaml> <idontwantausernamefeckoff> found it very funny when i opened the source code for stdenv and it’s just a bunch of one line wrappers for method calls

23:35 <companion_cube> It's not necessarily a bad idea, it gives better error messages

23:35 <companion_cube> But using # in types is really more ergonomic than anything else ocaml offers (records of functions, modules)