07:04 <discocaml> <sim642> What is `Warning 58 [no-cmx-file]: no cmx file was found in path for module Big_int_Z, and its interface was not compiled with -opaque` trying to say? I don't really get it because `big_int_z.cmx` is in `_opam/lib/zarith/`, next to `big_int_z.mli`, etc.

07:05 <discocaml> <froyo> I am a great supporter of the production of ice cream. The production of ice cream needs to be expanded as much as possible. I am lobbying for ice cream, because it is a very delicious and nourishing food.

07:05 <discocaml> <sim642> And yes, I should just port the code from `Big_int_Z` to `Z`, but I want to understand what's supposedly the issue

07:06 <discocaml> <froyo> `Big_int_z`

07:06 <discocaml> <froyo> (small z)

07:08 <discocaml> <sim642> Hmm no, it's all capital: https://github.com/ocaml/Zarith

07:08 <discocaml> <froyo> apologies, I was going by what you wrote

07:09 <discocaml> <sim642> I just typoed in the message indeed, the file has it capital actually

07:09 <discocaml> <sim642> I would've missed that detail, but that doesn't seem to be the actual reason

07:11 <discocaml> <nojb_77943> what is the command-line that is producing the message?

07:11 <discocaml> <sim642> It seems to be this from dune: `(cd _build/default && /home/simmo/dev/goblint/sv-comp/goblint/_opam/bin/ocamlopt.opt -w -40 -g -I src/ext/zrapp/.zrapp.objs/byte -I src/ext/zrapp/.zrapp.objs/native -I /home/simmo/dev/goblint/sv-comp/goblint/_opam/lib/stdlib-shims -I src/.goblintCil.objs/byte -I src/.goblintCil.objs/native -I src/ext/liveness/.liveness.objs/byte -I src/ext/liveness/.liveness.objs/native -intf-suffix .ml -no-alias-deps -open Zrapp

07:11 <discocaml> <nojb_77943> what is the command-line that is producing the warning?

07:11 <discocaml> <nojb_77943> I don't see the zarith directory listed here...

07:12 <discocaml> <nojb_77943> are you compiling with implicit-transitive-deps = false ?

07:14 <discocaml> <sim642> Oh indeed, I wasn't even aware of it. I guess that explains why the warning only comes up on one module that's not the one directly even using `Big_int_Z`

07:16 <discocaml> <nojb_77943> implicit-transitive-deps = false has some shortcomings in OCaml < 5.2, but should work well in >= 5.2.

07:17 <discocaml> <nojb_77943> You may also be interested in `(implicit_transitive_deps false-if-hidden-includes-supported)` introduced in Dune 3.20, see https://dune.readthedocs.io/en/stable/reference/dune-project/implicit_transitive_deps.html.

09:20 <discocaml> <sim642> Ugh, for a while I was confused why also couldn't reproduce the warning, even after `dune clean` and building with dune cache disabled, but then I realized it only happens in release profile

09:20 <discocaml> <sim642> Because the normal dev profile has everything with `-opaque`

09:20 <discocaml> <nojb_77943> Yes, that's right

09:22 <discocaml> <sim642> And then I was surprised why the warning only came up on one module, while there are multiple which work with the library that uses zarith, but none of those modules actually invoke any of the functions, so `Big_int_Z` isn't being linked there

09:24 <discocaml> <sim642> It would be neat to have some kind of tool which could tell, why and where a certain module is being linked in. Like, give the source code location for the actual usage

09:25 <discocaml> <sim642> It would also be useful for trimming down large binaries. I've used modulectomy to find out what weird modules have been linked in, but it doesn't have a way to easily tell exactly why each one has been included

09:25 <discocaml> <sim642> Although maybe this information isn't readily available at that point anymore?

09:27 <discocaml> <nojb_77943> Yes, `.cmx` files needed during _compilation_ in order to do cross-module inlining, but this happens relatively late during compilation, when it is no longer so easy to provide location information (and there is no location information readily available for the object being inlined).

09:30 <discocaml> <sim642> I suppose some multi-stage lookup maybe could work? To first get the module-level thing at the linking level and then go back to the individual module's compilation to find out where in that module is the usage?

09:30 <discocaml> <sim642> But maybe alias deps and other stuff also complicate it

09:33 <discocaml> <nojb_77943> Sure, there are things that could be done ... PR welcome! 🙂

09:47 <discocaml> <darrenldl> companion_cube: thank you for containers-data, very handy. Needed an immutable trie today.

14:53 <discocaml> <del.nox> Hi

14:53 <companion_cube> good to hear @darrenldl :)

15:17 <discocaml> <vbmithr.> Hi all

15:17 <discocaml> <vbmithr.> I have a weird issue when installing ocaml from opam on Archlinux, no matter what I do I can’t install 5.2/5.3 from opam (though it builds fine from the repo)

15:18 <discocaml> <vbmithr.> https://github.com/ocaml/opam-repository/issues/28438

15:26 <discocaml> <vbmithr.> Mmh actually I got the same result using ocaml repo, make install fails basically

15:27 <discocaml> <nojb_77943> Sounds like an issue with Autoconf. What's your Autoconf version ?

15:28 <discocaml> <nojb_77943> Do you have the `install` program installed?

15:43 <discocaml> <vbmithr.> 1.18

15:43 <discocaml> <vbmithr.> [vb@sita ~/code/ocaml]% which install

15:43 <discocaml> <vbmithr.> /sbin/install

15:43 <discocaml> <vbmithr.> Yeah it’s regular Archlinux

15:45 <discocaml> <nojb_77943> normally if `install` is in your PATH, `./configure` should choose it over the `install-sh` script... so something is amiss somewhere, but hard to say exactly from a distance

15:48 <discocaml> <vbmithr.> mmh interesting, thanks.

15:49 <discocaml> <vbmithr.> if I do INSTALL=/sbin/install make install it works

15:51 <discocaml> <nojb_77943> If the failure is only with OPAM, I suspect that`/sbin` is not being passed in the PATH, due to sandboxing and all that.

16:01 <discocaml> <jacob4466> hey im trying to set up ocaml and i keep running into problems when I try to run "opam init" in the command line. I keep getting the "cygwin setup failed to download" warning and then it fails to find a repository

16:04 <discocaml> <yawaramin> hi, try #windows-support

16:05 <discocaml> <jacob4466> will do, thanks

16:13 <discocaml> <vbmithr.> It is also with normal install from repo

20:46 <gahr> is `type choice = One [@name "one"] | Two [@name "two"] [@@deriving yojson] type obj = { a: string; b: int; c: choice } [@@deriving yojson] let () = Printf.printf "%s\n" (obj_to_yojson { a = "A"; b = 13; c = Two } |> Yojson.Safe.to_string)` expected to produce `{"a":"A","b":13,"c":["two"]}`, where the `c` member is an array?

20:48 <gahr> (same w/o the @name thing)

20:48 <dh`> that seems somewhat odd

20:49 <gahr> ah

20:49 <gahr> "Variants (regular and polymorphic) are represented using arrays"

20:50 <discocaml> <edhebi> I think I remember this one

20:50 <gahr> from the readme over at https://github.com/ocaml-ppx/ppx_deriving_yojson

20:50 <gahr> I wonder why...

20:50 <discocaml> <edhebi> iirc you can for some reason fix this by specifically having it be `module Choice = struct type t = ... [@@deriving yojson] end`

20:50 <discocaml> <edhebi> don't have a computer to check it tho

20:51 <gahr> let me try

20:52 <discocaml> <edhebi> (if that doesn't work defining to_yojson by hand also works but kind of sucks)

20:52 <gahr> yeah that was the other option

20:52 <gahr> nah, nesting in a module doesn't help

20:53 <gahr> I'll go with the custom to_yojson function, thanks

20:56 <discocaml> <edhebi> you could keep the [@@deriving yojson] and shadow the generated choice_to_yojson with a function that does the unwrapping

20:59 <discocaml> <edhebi> there's also ppx_deriving_yojson and ppx_yojson_conv which might do different stuff ?

21:00 <gahr> I'm using the former