01:21 <h0rror> hi folks, should one use merlin or ocaml-lsp these days? what's the consensus? also, does anyone have an nvim config with OCaml-specific bells and whistles to check out? :)

01:27 <companion_cube> just ocaml-lsp for me, and lunarvim knows about it

01:31 <h0rror> companion_cube: thanks, checking out lunarvim

01:41 <loopspace> I started with merlin but am trying to switch to lsp in emacs

01:53 <h0rror> getting lsp to work with 5.0.0 on arm64 is proving non-trivial unfortunately

01:56 <discocaml> <Kali> i currently use merlin+nvim, but i've never used ocaml-lsp. does it offer any particular advantages to merlin?

02:05 <h0rror> visual studio code magically works without any configuration though

02:18 <companion_cube> lsp is just the standard now

02:18 <companion_cube> merlin works, but really, if you use multiple languages, using lsp is a no brainer

04:52 <loopspace> Is there something else I need to install? *lsp-log* keeps spewing the same error message in emacs https://www.irccloud.com/pastebin/X3szNvuZ/

04:53 <loopspace> (Things appear to be working to some extent, but I'm new to this setup, so I haven't tried much so far)

09:43 <discocaml> <dumbpotato> could anybody please answer my question in the beginners channel ☹️ i’ve been stuck on it for over 5 hours

19:30 <Anarchos> hello

20:04 <adrien> so... packing my values didn't help much I think; or at least not noticeably enough at the moment; I think the interval map itself uses quite a lot of memory; intervals are only 2 bytes on average

20:06 <olle> Can't you fork?

20:06 <olle> Hm that wouldn't reduce the total mem usage

20:07 <olle> adrien: what about distributed computing?

20:07 <adrien> but I was able to run this on my larger dataset by calling Gc.compact regularly; it still used 44GB

20:07 <adrien> I don't think it can be distributed easily but I might be able to turn the tree into an array

20:08 <olle> adrien: How big is the code eating the memory? In LOC

20:08 <adrien> another option is to turn the tree (the map) into a set of trees instead so that they can be freed as the rest of the program continues

20:08 <adrien> batteri's batimap

20:08 <adrien> basically

20:09 <olle> adrien: Would arenas help? Or pools or whatever.

20:11 <adrien> hard to tell; I have a few things to try before such things

20:12 <olle> Splitting it up sounds like a good idea.

20:12 <olle> If possible.

20:13 <olle> We have a PHP script that takes 15 min to run to export a data set, but didn't look into it yet. It's more about SQL opt, I'd assume. Still, customer was annoyed.

20:14 <adrien> I'm trying to optimize my type first but overall the boxing and use of large ints everywhere kind of hurts

20:20 <olle> That shouldn't be a problem if you can split it? Divide and conquer.

20:22 <adrien> the issue is that the data at any point can use anything that appeared previously

20:38 <adrien> I had type t = Padding | Literal | Match of int * int * int, and I was actually able to remove Padding now (it was useful when the code was still in flux) and then I was able to use only int * int * int because that second int being equal to 0 can be use to mean Literal

20:39 <adrien> and if I pack that type, I save around 1GB out of 11.5GB

20:40 <adrien> but it's also a bit surprising that the simpler type saved nothing by itself and I'm wondering if I'm leaking; which is going to force me to be kinda scientific and actually use memprofstat

20:55 <octachron> int * int * int is still "header + 3 fields".

20:57 <adrien> since the memory usage is slightly lower in practice when packing, I'm probably missing something else, which is why I'm thinking of some kind of leak

21:42 <olle> adrien: write old data to disk and remove it from RAM_

21:42 <olle> ?

21:43 <olle> What does "at any point" mean?

21:43 <olle> Like, statistically?