03:47 <discocaml> <anmonteiro> I think you want to use Configurator: https://dune.readthedocs.io/en/stable/dune-libs.html#configurator

03:47 <discocaml> <anmonteiro> You might want to use Configurator: https://dune.readthedocs.io/en/stable/dune-libs.html#configurator

04:35 <greenbagels> so yojson seems to be an extremely popular json library but it is (by its own admission) pretty low-level; to use it natively to deserialize JSON objects into ocaml data types is a pretty verbose process

04:36 <greenbagels> am i wrong in thinking people use some kind of code generation / metaprogramming to deserialize json data in practice?

05:03 <discocaml> <bluddy5> Easiest way is to use ppx_deriving_yojson

05:08 <greenbagels> would you say that is the most common way people use it? hmm

05:10 <discocaml> <bluddy5> I don't know. I know that I have no patience to describe how to serialize or deserialize objects. I serialize my entire game state like this.

05:29 <greenbagels> i feel ya

05:31 <companion_cube> json for a game, tho… 😅

05:34 <discocaml> <bluddy5> it's fine. makes it easier to debug

05:34 <discocaml> <bluddy5> I can switch to a binary format later

05:40 <greenbagels> i guess my question boils down to more than just asking about json itself; i guess im getting to the point where i have to understand the extent to which preprocessing is idiomatic in ocaml

05:40 <greenbagels> so i will read https://ocaml.org/docs/metaprogramming for now

07:30 <discocaml> <bluddy5> Some people will tell you it's not essential. I beg to differ. Once you start scaling up, you cannot afford to spend time on basics like serialization for every data structure.

11:25 <companion_cube> Yeah at this point it's fairly important imho

11:26 <companion_cube> But I have colleagues who use elm-style encoders, so, combinators, and it works well enough

11:49 <discocaml> <tym972> Hello, I have a problem with my OCaml environment. I'm on Windows, and I work with VS Code on Ubuntu. I am trying to install unionFind module, for that I did opam install unionFind in console. By doing #require in utop, I access the functions, but the problem is that I can't do "open UnionFind" in my source files, the module is not recognized. Could someone guide me?

12:18 <discocaml> <octachron> You need to communicate to your build system which library you are using.

12:24 <discocaml> <octachron> With dune this means adding the library to your `libraries` stanza.

13:11 <discocaml> <tym972> I'm novice, how do we do it? I think I use dune but there is no dune file in my Workspace root.

13:49 <discocaml> <octachron> If you don't have a `dune` file nor a `dune-project` file, you have not yet set up dune for your project. The `dune-project` file can be as short as `(lang dune 3.0)` whereas the `dune` file should contain something like `(executable (name my_project_name) (libraries unionFind))`.

14:01 <discocaml> <contificate> Nice to see that I can't be the only one that sometimes uses `3.0` to permit being able to just do projects as a single folder endeavour.

14:09 <companion_cube> why wouldn't that work with 2? :)

14:20 <discocaml> <contificate> Gotta be as modern as possible whilst also sticking to your principles, unless you're telling me `dune` major versions work decrementally, and we're about to converge on the perfect build system with version 0.

14:30 <companion_cube> hmm no, I just try to not force my users to use the most recent version of things

14:30 <companion_cube> (in this case, in particular, upgrading dune is a PITA because you have to recompile your whole switch)

18:43 <olle> Hm isn't Menhir parsing in order in the parser file?

18:43 <olle> Eagerly, that is

18:45 <discocaml> <._null._> I don't think so ?

18:45 <olle> No?

18:45 <olle> Asking ChatGPT too

18:47 <olle> I have

18:47 <olle> | "SplDoublyLinkedList" {List Infer_me: Ast.typ}

18:47 <olle> | s=CLASS_NAME {Class_type (s, Infer_allocation_strategy) : Ast.typ}

18:47 <olle> But it seems to alway choose S=CLASS_NAME

18:48 <olle> Because it's more general...? o0

18:48 <discocaml> <._null._> Does it complain about conflicts ?

18:48 <olle> Eeeeh

18:49 <olle> Warning: 9 states have shift/reduce conflicts.

18:49 <olle> Warning: 34 shift/reduce conflicts were arbitrarily resolved.

18:49 <discocaml> <._null._> If so, they get solved arbitrarily but you should really fix them

18:49 <olle> Stuff like that??

18:49 <discocaml> <._null._> Yes, stuff like that

18:49 <olle> ><

18:50 <discocaml> <._null._> Don't worry too much about the high numbers, it's like compiler errors in compilers which don't stop at the first

18:50 <olle> OK but how to now which "state" is faulty?

18:50 <olle> know*

18:50 <discocaml> <._null._> Add the tag `--explain` and [try to] read the generated file

18:51 <olle> null in the dune file?

18:52 <discocaml> <._null._> No, this generates a "conflicts" file IIRC. unfortunately it gets placed in `_build`

18:52 <olle> https://github.com/ocaml/dune/issues/6865

18:54 <olle> Gah

18:57 <olle> Lemme just do an ugly hard-code there instead... :d

19:02 <olle> https://discuss.ocaml.org/t/how-to-use-menhir-explain-with-dune/

21:11 <greenbagels> alright friends youve convinced me with very minimal effort

21:11 <greenbagels> ppxes are cool