11:46 <oriba> If I call C-functions from OCaml, do I have to use CAMLprim for the function that is called from OCaml? I have seen examples, where C-functions only have type value.

11:50 <def> C-functions called from OCaml are restricted to taking and returning values

12:01 <oriba> how to give back double-value from C to OCaml?

14:03 <flux1> oriba: there's a C function that takes a C double, allocates a boxed ocaml-float and then returns that.. I don't recall if it might be valled Val_double or Double_val or something :)

14:03 <flux1> at least I'm 98% sure there is :)

14:04 <oriba> flux1: yes, found out that I have to use caml_alloc_float_array() for allocation (instead of caml_alloc()) and Store_double_field() instead of Store_field.

14:06 <oriba> but IÄm not sure if I have to use Camllocal<n> for a value that I don't give back and just store into the result, which is given back.

14:06 <malc_> flux1: caml_copy_double?

14:07 <flux1> malc_: sounds very likely :)

14:08 <malc_> tres bien

14:08 <flux1> oriba: I believe you do need to use Camllocal for those values

14:10 <oriba> but my value is a true C-double, not a value variable... Does Store_double_field(result, 0, Double_val(mydouble)) work with mydouble being a double[1] mydouble?

14:13 <flux1> hmm, I think Double_val is intended to convert from OCaml values to C values, right?

14:13 <flux1> so if mydouble is a C value, then it's not the right function to call

14:14 <flux1> "Double_val(v) returns the floating-point number contained in value v, with type double." and "Store_double_field(v, n, d) stores the double precision floating-point number d in the nth element of the array of floating-point numbers v.", so the latter takes plain C doubles and stores them inside OCaml heap

14:14 <flux1> https://caml.inria.fr/pub/docs/manual-ocaml/intfc.html

14:17 <oriba> ooops

14:18 <oriba> flux1: it worked, but seems to be the wrong function, yes. Val_double(mydouble) hmhhh

14:18 <oriba> errormessages ... hmhhh

14:19 <oriba> caml_copy_double ??

14:19 <oriba> I wonder why it compiled nicely with the wrong function...

14:25 <adrien> isn't that always the case with C stubs? ;p

14:27 <oriba> but it even gave back the right value...

14:28 <adrien> :D

14:28 <adrien> would have to take a deep look at the code but not sure I feel like doing that :P

16:02 <oriba> who is editing the opam-package-entries? Is there a centralized instance?