12:03 <discocaml> <Alistair> Is there a way to unbox an existential type if you know its parameters will only be instantiated to non-float values?

12:05 <discocaml> <NULL> What do you mean exactly ?

12:08 <discocaml> <Alistair> E.g. for the GADT tag ```

12:08 <discocaml> <Alistair> type 'a tag =

12:08 <discocaml> <Alistair> | Tag1 : t1 tag

12:08 <discocaml> <Alistair> | ...

12:08 <discocaml> <Alistair> | Tagn : tn tag

12:08 <discocaml> <Alistair> ```

12:08 <discocaml> <Alistair> This (at runtime) is simply represented as an integer.

12:08 <discocaml> <Alistair> However, suppose I was an existential type for this tag:

12:08 <discocaml> <Alistair> ```

12:09 <discocaml> <Alistair> type ex_tag =

12:09 <discocaml> <Alistair> | Ex_tag : 'a tag -> ex_tag

12:09 <discocaml> <Alistair> ```

12:09 <discocaml> <Alistair> The only way to achieve this is with boxing since OCaml cannot infer whether some instantiation of `'a tag` will be an int / pointer / float -- but statically (regardless of what `'a` is instantiated with) we know `tag` will be represented as an int

14:15 <discocaml> <wokalski> What are the recommended tools to use for profiling in OCaml 5? Memtrace doesn’t work ((Failure "Gc.memprof.start: not implemented in multicore")), spacetime is long gone and we have this pretty unhelpful stack trace to look at. Before we start dissecting our codebase to empirically find what the issue is, could you suggest any tooling to find where the issue lies? I am sure that excessive allocations are the issue but I have 4 different ar

14:54 <hannes> wokalski: I'd try landmarks (ppx from lexifi) and instrument first the top-level module, and then going down the callchain.

14:55 <hannes> https://github.com/LexiFi/landmarks

14:55 <hannes> or linux' perf

15:03 <discocaml> <wokalski> With landmarks I struggled to set it up properly for libraries (I have a setup where I have bin/main.ml and the rest in lib to be able to have inline tests). When I added landmark.ppx to the underlying libs I got a runtime exception from landmark. `failure when closing expecting "ROOT"` in the library code

15:07 <discocaml> <wokalski> but you'r eright that the easiest option (althoguh not easy per se) besides the linux perf is manually instrumenting the code with landmark.

15:19 <hannes> sorry to hear your struggle with landmarks, for me it worked nicely (but I have not used OCaml 5 yet)

15:27 <discocaml> <arbipher> I wonder how can I create an issue (or maybe a PR) for projects hold in gitlab.inria.fr. The registration seems not open to public (or the ocaml community)..

17:31 <reynir> perhaps you can contact the author by email

19:15 <discocaml> <leviroth> @TheBloodlessMan I think you should be able to use the `[@@unboxed]` annotation there, does it not work?

19:18 <discocaml> <leviroth> Indeed I don’t think it should matter that the contents of the existential type there must be immediate; all that matters is that there’s only one constructor, so you don’t need an extra box to represent this type. It should also work if you had `type t = T : _ option -> t [@@unboxed]`

19:43 <discocaml> <octachron> @arbipher , I fear the only option is to send an email (possibly on the project mailing list). The Inria gitlab instance is mostly unusable.

19:44 <discocaml> <octachron> (at least for open source projects)