<discocaml>
<contificate> Does `dune` let you use that option that `ocamlopt` gives you to globally `open` a module? That'd be neat for pervasive modules you want to invent
<discocaml>
<yawaramin> yes just set it as a compiler flag
bartholin has quit [Remote host closed the connection]
bartholin has joined #ocaml
bartholin has quit [Quit: Leaving]
Haudegen has joined #ocaml
<discocaml>
<otini_> @companion_cube :
<discocaml>
<otini_> >So if you get partial, possibly misleading data, meh
<discocaml>
<otini_> the ring buffer loses events only when old, unconsumed events get rewritten
<discocaml>
<otini_> so to lose events you have to either not consume them or consume them too slowly for a long time
<discocaml>
<otini_> it’s not like some events are dropped at random
Haudegen has quit [Quit: Bin weg.]
<adrien>
heh, it looks like that if I Lwt_domain.detach something that uses lambdasoup, I get weird errors inside lambdasoup
<adrien>
(I'm lucky that this computation only takes around 1s now but I'll see if I can detach it myself to its own domain)
<discocaml>
<otini_> what does it do?
<discocaml>
<otini_> also why using Lwt?
<companion_cube>
@otini_ sure, but it can happen if you have a large burst of events
<companion_cube>
In any case I could also use the ring buffer from my library if needed, as a backend
Haudegen has joined #ocaml
<discocaml>
<otini_> assuming scheduler fairness, I don’t see why it would be hard to write a thread/external tool that consumes any frequency of events fast enough
<companion_cube>
That's a big assumption
<companion_cube>
And the external tool, if it writes to disk, might still be slower than the producer. There's no backpressure.
<companion_cube>
Tbh it's probably fine for live tracing and metrics in general, but the way I use tracing sometimes is a bit more data intensive.
<discocaml>
<otini_> mm, okay, I guess it’s designed with events that are not so frequent in mind
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<discocaml>
<otini_> it wouldn’t be very hard to have pluggable backpressure, probably
<discocaml>
<otini_> by default there isn’t and external programs could provide a callback when the buffer is full, which if present would be called in a stop-the-world fashion
raskol has joined #ocaml
<companion_cube>
I'm not sure it's designed for back pressure really
<companion_cube>
Anyway, it's a more specific use case imho
<adrien>
otini_: Lwt_domain.detach does a computation in a different domain which is handy if you have a non-cooperative task that can take a while to run; there's also Lwt_preemptive.detach which does the same but merely using a thread
<adrien>
I'm attempting to use it right now and I'll see if it avoids the issue
<adrien>
also, why lwt: because I started quite some time ago and using ocaml 4.14
<adrien>
I'm also not familiar with Eio (and effects!) at all
<companion_cube>
adrien: another possible workaround is to make sure to initialize it before creating domains
<adrien>
companion_cube: ohhhhh
<adrien>
well, I was using a domain pool of size 1 but I think I also have some operations in the main domain
<adrien>
which are tiny operations so I don't feel like changing things for them
gareppa has joined #ocaml
<adrien>
it seems to be working well with lwt_preemptive instead
<companion_cube>
sure but you don't get parallelism
gareppa has quit [Quit: WeeChat 4.3.1]
gareppa has joined #ocaml
gareppa has quit [Client Quit]
<adrien>
yes; I think it'll be fine, or at least it seems fine for now and I'll monitor
<adrien>
the amount of work depends on external inputs and there is less to do ATM compared to a few days ago but I think that performance is acceptable after some performance optimizations I did (I think I was hitting terrible codepaths in lambdasoup somehow)