00:28 <dh`> masterbuilder: that's coming from a very specialized corner of things

00:28 <dh`> oops

12:26 <gzar> Hey there, I was wondering if anyone here knows about a good way to mix ocaml and java. Besides OcamlJava because its kind of not beeing developed much and is still at version 4.01.0

12:32 <discocaml> <lukstafi> What's the easiest way to open a file and get its `FILE*` -- C file pointer?

13:25 <companion_cube> You can't

17:02 <gzar> Whats the correct way to use a 3rd party library? I've install tgls, but when I try to do 'open Tgl3' like the doc states, it just cant find the module.

17:03 <gzar> its installed in ~/.opam/5.1.1/lib/tgls

17:04 <gzar> Do I have to setup a dune project to be able to reference this module?

17:08 <discocaml> <yawaramin> your best option is to use dune, it will take care of the details of compilation and is the currently supported build tool of the OCaml Platform

17:17 <gzar> alright, I just thought that just referencing the module would work in like an ocaml top-level or a lone .ml file

17:48 <companion_cube> Use dune or `#require` in utop

17:53 <gzar> thanks

18:15 <discocaml> <yawaramin> utop is a REPL so slightly different use cases

18:25 <companion_cube> Tbh I mostly use `dune utop`, rarely utop alone

19:48 <rustyne> gzar: OCaml compilers don’t know much about packages, they must be told explicitly where to look for modules, etc. with `-I`

19:49 <gzar> rustyne: even if its in a standard location like .opam/default/lib ?

19:49 <rustyne> dune or ocamlfind are there to feed them that info (among many other goals, for dune)

19:49 <rustyne> yes, OCaml doesn’t know about OPAM :-)

19:49 <gzar> ooh right

19:50 <gzar> they come installed together, so I kind of assumed there is some level of shared code or something

19:52 <gzar> thats actually pretty good, using # ocaml -I `ocamlfind query tgls.tgl3` I can now do what I expected.

19:54 <discocaml> <yawaramin> it's a layer system. OCaml distribution is the innermost layer and it doesn't know about anything else. opam is the layer outside that which knows where packages are installed. dune is the layer outside that which knows how to build the project. this way everything can be swapped out in the future if need be.

20:37 <rustyne> I often use `dune build --verbose` to see how the compiler is actually invoked to build, by the way

20:39 <companion_cube> or look at _build/log