07:54 <discocaml> <functionalprogramming> does the code i have here (moving signature from mli+ml to a separate sig file) properly allow for separate/incremental compilation? https://github.com/mizlan/indexedmap/tree/main/lib

12:51 <discocaml> <octachron> Your `sig` module doesn't change much in term of incremental compilation: any changes to the signature will now happen in your `sig` module, which will trigger a recompilation of both the interface and the implementation of `indexedmap`.

14:04 <discocaml> <akashi_the_mechanic> I feel dump here. Which module should I use given I have worked with regex of Java/JS standard library?

14:04 <discocaml> <akashi_the_mechanic> https://cdn.discordapp.com/attachments/436568060288172044/1180147389567340686/image.png?ex=657c5ce7&is=6569e7e7&hm=3bbb0ccd6caada124291bdc3cecc8805afc45c824c7b0a48577d9cb9a7b45d6c&

14:14 <discocaml> <octachron> Probably the Perl one?

14:26 <discocaml> <akashi_the_mechanic> Probably the perl one, sadly, this library doesn't support look-ahead

14:26 <companion_cube> you could use pcre2 I think, it's bindings to the perl library

14:33 <discocaml> <akashi_the_mechanic> The opam page point me to this repo: https://github.com/camlp5/pcre2-ocaml

14:33 <discocaml> <akashi_the_mechanic>

14:33 <discocaml> <akashi_the_mechanic> > I do not plan on maintaining this repository.

14:33 <discocaml> <akashi_the_mechanic>

14:33 <discocaml> <akashi_the_mechanic> The read me is concerning tho 🤔

14:35 <discocaml> <octachron> On the other hand, you have Haxe in the dependency chain.

14:36 <companion_cube> oh this is pcre2, ok, right

14:36 <companion_cube> there's also pcre

14:37 <companion_cube> I have no idea if pcre2 is better, but the pcre bindings are by mmottl so they must be really good quality :)

14:37 <companion_cube> https://mmottl.github.io/pcre-ocaml/

17:09 <trev> is it ok to ask AoC questions here?

17:12 <octachron> Certainly

17:13 <trev> is there a way to simplify the map function here? namely removing `fun s -> s` : https://github.com/trevarj/advent-of-code/blob/159f42bd1e2dce1a0be3a8cc7a99eb3edcf11697/2023/aoc_ocaml/lib/Day1.ml#L38-L39

17:22 <octachron> You could keep the sequence and pipe `Seq.map`s. Otherwise, you can define the left-to-right composition operator `let (%>) f g x = g (f x)`

17:24 <trev> yesss the composition is what i was looking for. couldn't find it like in haskell

17:25 <trev> not sure about the Seq.map though

17:25 <octachron> also you can replace the patter `'X' :: rest` -> ... ('X' :: rest)` by `('X' :: _ as rest) -> ... rest`

17:27 <octachron> Indeed, `Seq` doesn't work in this case

17:34 <trev> the composition worked great, thanks octachron

19:18 <companion_cube> TRMC is going to be so nice, damn

19:18 <companion_cube> speeding up some parts of CCList right now

20:28 <Armael> CCList goes vroom?

20:36 <companion_cube> goes BRRRRRR

20:36 <companion_cube> a bit at least

20:37 <companion_cube> should be faster on smaller lists, ±same on longer lists, and less memory pressure

20:48 <greenbagels> companion_cube: you need to make a module named ccache to annoy the c/c++ programmers

20:49 <companion_cube> :p

20:52 <companion_cube> https://github.com/c-cube/ocaml-containers/pull/443/files brrrrrrrrr

21:10 <Anarchos> dune (trunk version) is missing vendor/csexp ?

23:33 <discocaml> <contextfreebeer> what's the best way to determine which function a nested function belongs to from its "mangled" name? I'm trying to determine which of the "go" functions in a library I'm using is so hot but the only thing that shows up in the profiler is go_860 which isn't helpful. there are two functions it could be, I have a hunch which one but I want to make sure

23:35 <discocaml> <contextfreebeer> I had the idea to run it in gdb with a breakpoint on that function and get a backtrace, so now I know, but still curious if there is a better way in general