02:22 <discocaml> <lroche> I remember a message that is probably less than 2 or 3 years old (probably in the forum or github) about file embedding becoming different in a "recent" ocaml because parsing of raw strings changed. Probably something about \r\n and \n being normalized or something like that. Basically making what is suggesting in https://www.reddit.com/r/ocaml/comments/quqgqk/embedding_a_file_as_a_string_at_compile_time/ invalid for binary content. But I can't

02:25 <discocaml> <lroche> maybe related to https://github.com/ocaml/ocaml/blob/b58aafcdd1335fd0d13ab6214a6a884dfb9b87ab/Changes#L48-L55

02:26 <companion_cube> 404 :/

02:29 <discocaml> <lroche> which link is 404?

02:29 <companion_cube> ah, had to resize my window, sorry

02:29 <companion_cube> part of the URL was cut 😅

02:30 <discocaml> <lroche> I'm starting to think that the message was posted when there was all the discussions about attacks with invisible chars. Getting old, my memory is failing me

02:31 <discocaml> <lroche> anyway if you don't remember immediately please don't spend time on it, the changelog is probably enough of a justification to use crunch/ppx_blob instead of manual embedding

02:33 <companion_cube> how does crunch work, actually?

02:33 <companion_cube> I can imagine that ppx_blob can directly create an AST node, which is really efficient

02:35 <companion_cube> https://github.com/mirage/ocaml-crunch/blob/main/src/crunch.ml#L152 ok, %S, so also problematic on windows I guess

02:35 <companion_cube> (just like what I generally do)

14:01 <discocaml> <.armael.> Wasn’t there a recent change in trunk wrt this \r situation?

14:02 <discocaml> <lroche> Yes. Somehow I thought it was 2 years old but it’s actually very recent

14:03 <discocaml> <.armael.> Ah ok I see

14:09 <companion_cube> So only ppx_blob will be correct now?

14:11 <discocaml> <dinosaure> it apply only for `{|` and `|}`, no?

14:13 <discocaml> <dinosaure> it applies only for `{|` and `|}`, no?

14:17 <companion_cube> Sure but that's generally what I use for that

15:50 <discocaml> <dinosaure> can we "safely" use `Obj.magic` from a `(char, int8_unsigned_elt, _) Bigarray.Array1.t` to a `(int32, int32_elt, _) Bigarray.Array1.t` ?

15:57 <discocaml> <drupyog> @octachron on peut utiliser merlin sur le typeur en ce moment ? Il faut faire quoi ?

15:57 <discocaml> <drupyog> @octachron can we use merlin on the compiler right now ? how ?

16:01 <companion_cube> (try another language)

16:04 <discocaml> <octachron> `dune build @check` should half-work enough to enable merlin

16:08 <discocaml> <drupyog> it doesn't seem to really work right now

17:28 <discocaml> <octachron> It works for me on today trunk. You need to start from a clean tree and ignore any errors.

20:20 <greenbagels> hmm i dont remember if ive asked this before, but is there any reasonably supported cross compilation setup for linux -> windows with ocaml 5?

20:21 <greenbagels> (or even 4.14)

21:39 <remexre> does ocaml guarantee any tail-call properties of the stdlib? e.g. is Option.bind guaranteed to tail-call f

21:40 <companion_cube> you have to look at the implementation

21:40 <companion_cube> some things became tailcall recently (e.g. List.map)

21:41 <remexre> my quesiton is more of a stability one, I guess; like, is it guaranteed that the stdlib won't make something no longer be a tail call

21:42 <remexre> (Option.bind is right now and I can't think of a reasonable implementation that isn't, but it'd be nice to have a guarantee to cite that "no this actually won't blow up")

23:21 <discocaml> <silverneedles> is there a name for functions that have the type keyword in their parameters?

23:22 <discocaml> <silverneedles> for example,

23:22 <discocaml> <silverneedles> `let group_by (type k) ?(hash = Hashtbl.hash) ?(eq = Stdlib.( = )) l = ...`

23:22 <discocaml> <silverneedles> not sure what to look up to find info on that construction

23:28 <discocaml> <deepspacejohn> it's a "locally abstract type"

23:29 <discocaml> <deepspacejohn> https://v2.ocaml.org/releases/5.1/manual/locallyabstract.html

23:33 <discocaml> <silverneedles> thanks!!