06:27 <greenbagels> ok i resolved my earlier project design issue but now i have another dune question

06:28 <greenbagels> say i have two modules src/a.ml and src/b.ml and dune is configured to collect every module in src/ into a library

06:28 <greenbagels> is there any way to have code in src/b.ml depend on functions in src/a.ml?

07:23 <discocaml> <andreypopp> Just refer to functions in a.ml via A module, dune should figure out dependencies automatically

07:29 <greenbagels> ah, thanks for the tip! it made me re-check my code and realize i was just typoing the module name :p

09:27 <discocaml> <andreypopp> so some time ago I was asking if there's a simplified deriving framework, I have this now https://github.com/andreypopp/react_of_ocaml/blob/main/ppx_deriving_schema/ppx_deriving_schema.mli

09:27 <discocaml> <andreypopp> was able to build deriving yojson in under 200LoC, same for deriving melange json https://github.com/andreypopp/react_of_ocaml/blob/main/ppx_deriving_json/ppx_deriving_yojson.ml

09:28 <discocaml> <andreypopp> it does have some assumptions like having same repr for variants and polyvariants but overall it reduces boilerplate quite a lot

10:13 <discocaml> <fabric.input_output> hello, why do I get this error ```

10:13 <discocaml> <fabric.input_output> 1. Unbound value sexp_of_data

10:13 <discocaml> <fabric.input_output> Hint: Did you mean sexp_of_mat?

10:13 <discocaml> <fabric.input_output> ```

10:13 <discocaml> <fabric.input_output> in this part of the inline test: ```ocaml

10:13 <discocaml> <fabric.input_output> [%test_eq: data] foo bar

10:13 <discocaml> <fabric.input_output> ```

10:13 <discocaml> <fabric.input_output> it erroring about `data`, which is a type I have defined just above the test. I can do `[@@deriving eq]` on the type but I can't seem to be able to do `[@@deriving sexp]`, which is probably the solution.

10:21 <discocaml> <fabric.input_output> I managed to do `[@@deriving sexp]` but it still errors

11:46 <discocaml> <ambersaber> hello

11:47 <discocaml> <ambersaber> i love ocaml language

18:53 <src> is there a way to suppress creation of auxiliary files .cmx .cmi .o when using ocamlopt

18:53 <src> I find no such flag in the man page and keep writing one off little puzzle solvers where I need only the executable

19:07 <octachron> .cmx, .cmi and .o are a necessary part of the compilation process.

19:18 <discocaml> <Kali> if you really don't want them, then execute it with ocaml instead of ocamlc/opt

19:18 <discocaml> <Kali> which will certainly be slower, but it doesn't produce those files

19:19 <discocaml> <Kali> or you can just remove the files after they're made

20:30 <discocaml> <ds_trop_cringe> @orangecatjunior come in vocal

21:09 <dh`> src: just write a makefile that leaves them in a subdir

21:12 <companion_cube> use dune and it'll all be only in _build

22:21 <greenbagels> are there general principles for when to use vs avoid closures

22:21 <greenbagels> performance implications? code cleanliness? etc

22:33 <companion_cube> I'm not sure what the rule would be :)

22:33 <companion_cube> use closures when it makes sense

22:46 <discocaml> <deepspacejohn> Yeah I’m not aware of any special reasons to use/avoid closures in general. For performance, it probably depends on what how alternative code for your use case performs.