04:14 <GeoffK> Merlin giving "Not in environment ’<symbol>’" - other things like C-c C-t work.

04:15 <GeoffK> + from within emacs.

12:37 <hannes> hmm, does the OCaml runtime use the same calling semantics as C (I guess the answer is yes)? or, is there a custom "C stack" and "OCaml stack" (I guess the answer is no)?

12:39 <Armael> I think there is indeed a C stack separate from the ocaml stack

12:39 <def> hannes: yes in bytecode, no in native non multicore

12:40 <Armael> oh.

12:41 <hannes> oh interesting, thanks

12:42 <def> in bytecode: the ocaml stack is basically a value array, ocaml calls appear in the C stack as calls to caml_interprete functions.

12:43 <def> so to unroll the stack 1) you unroll C calls until you reach an instance of caml_interprete, then you unroll until you reach a marker that goes back to C function, etc.

12:43 <def> in native non multicore, you can have a mix of C and OCaml frames on the callstack.

12:44 <def> calls to C externals with noalloc flag appear directly on the stack and are leaves, as far as the OCaml runtime is concerned (you cannot go back to OCaml code inside a call to a noalloc external).

12:44 <def> the compiler generates the code to switch from the OCaml calling convention to the C one

12:45 <def> for non-noalloc calls, calls to the caml_c_call primitive are inserted between OCaml and C frames in the stack.

12:45 <def> caml_c_call acts as a bridge between C and OCaml calling convention.

12:46 <hannes> ah

12:46 <def> in multicore world, the situation was more complex last time I checked. You have one C stack per domain (~ pthread managed by the runtime, rougly mapping to one logical CPU core), that is managed like the native stack from singlecore OCaml.

12:48 <def> But once you start using effect handlers, stacks are allocated in the OCaml heap and are regular OCaml values. Therefore calls to C have to go back to the system stack so the trampoline is a bit more complex.

12:57 <hannes> def: the effect handlers -- sth i'm interested in since years (even with a single-core runtime) -- are still in the process of getting upstreamed to ocaml-trunk (as in: they're not part of the 4.10/4.11 runtime)?

13:00 <def> no, effects will come later. The type system has not been figured out yet. The runtime is in a better shape but right now the focus is on multicore GC afaik.

13:43 <Anarchos> i converted my project to dune instead of handcrafted makefile. How should i generate the .merlin files ?

13:43 <companion_cube> dune will do it automatically

13:47 <Anarchos> companion_cube in _build ?

13:51 <companion_cube> no, in the source tree

13:51 <reynir> I think dune build @check will generate .merlin for you (or just dune build, but that does more)

13:56 <Anarchos> reynir thanks

14:37 <Anarchos> companion_cube it didn't (i use dune 2.4.0)

14:38 <companion_cube> did you build your project?

14:39 <Anarchos> yes with dune build @all

14:39 <companion_cube> works for me 🤷

14:42 <reynir> ^

14:52 <Anarchos> companion_cube i pushed my dune config files on my github repos, if you would be kind enough to look at

14:52 <companion_cube> does dune build anything?

14:52 <companion_cube> like, libraries, binaries, etc.?

14:57 <Anarchos> companion_cube yes it builds

14:58 <companion_cube> are you sure the merlin files are not there? they're hidden files

15:10 <Anarchos> companion_cube i amsure (ls -a)

15:10 <companion_cube> try to clone another project that uses dune, and do the same command

15:11 <companion_cube> for example I know it works for containers

16:19 <Anarchos> companion_cube which repo ?

16:20 <companion_cube> https://github.com/c-cube/ocaml-containers

16:22 <Anarchos> companion_cube of course, i should remembered it was your repo