00:30 <companion_cube> dh`: I don't understand what you want

00:30 <companion_cube> Lwt definitely has sub second sleep

00:31 <companion_cube> And to get the current time you don't need lwt at all

02:06 <dh`> I must have been looking in the wrong place then

02:06 <dh`> the documentation for Lwt_timeout says int -> (unit -> unit) -> t

02:07 <dh`> and what I'm actually trying to do is tick n times a second

02:11 <dh`> (and this is using lwt because of a pile of webgoop that's written on top of it)

02:14 <companion_cube> use Lwt_unix.sleep

02:19 <dh`> after considering options I used Lwt_preemptive.detach

02:21 <companion_cube> just be aware that Lwt_unix.sleep is far more lightweight

02:25 <dh`> not significant here :-)

02:26 <dh`> already have another Lwt_preemptive.detach because I couldn't get lwt to run a real background thread

02:26 <dh`> which was probably because I couldn't figure it out under deadline pressure, not because it can't

09:19 <discocaml> <darrenldl> what do you lot use to manage development environment? (say ocaml compiler + opam packages, and also maybe IDE + lsp)

09:19 <discocaml> <darrenldl> just install directly? nix? VM?

09:21 <raphaal> opam + emacs

09:23 <discocaml> <darrenldl> install directly into user directory? no separation from actual home directory?

09:25 <raphaal> yes, but I'm not ocaml power user, so this is fine for me

09:25 <raphaal> I have one ocaml version

09:26 <discocaml> <darrenldl> do/would you do the same with other langs with (usually) heavier IDE dependencies? e.g. java + intellij

09:26 <discocaml> <darrenldl> just working out how much i need to worry about packaging projects up neatly. maybe not very much.

09:28 <raphaal> python -> virtualenv, so no, I have environ per project

09:28 <discocaml> <darrenldl> gotcha. thanks!

09:29 <raphaal> ok, so maybe I have the same question, how to manage different ocaml environments?

09:32 <greenbagels> an unrelated question, to add to the question hour

09:33 <discocaml> <darrenldl> raphaal: my (somewhat unsatisfactory) answer so far is to chug everything into podman/docker, since i want the additional separation anyway when working with other people's project (in case it accidentally deletes home, steals ssh keys, etc)

09:34 <greenbagels> are there any general rules to how aggressively the ocaml compiler optimizes? for example, if i iterate over a list from front-to-back linearly with List.nth, is it smart enough to make each iteration O(1), or will it still be O(n) per .nth lookup?

09:35 <discocaml> <darrenldl> as in between multiple calls to List.nth?

09:35 <greenbagels> Yeah

09:36 <discocaml> <darrenldl> yeah i don't think it'd cache/memoize the result for you

09:38 <discocaml> <darrenldl> my guess is it's not a sound optimisation w.r.t. mutation, secondly is how do you determine if it's likely that the `n` in each run will be same and you should actually cache the result in the general case

09:38 <discocaml> <._null._> Without flambda, ocaml optimises quite few things; pretty much only the primitives (equality, comparisons, tail calls and closures) I think. This is part of why it is fast and executable speed is predicatable

09:38 <octachron> greenbagels, your List example is a change of your algorithm complexity, you can be nearly certain that the compiler will never do that for you.

09:39 <greenbagels> octachron: right because it would basically have to break apart the nth calls and whatnot

09:39 <discocaml> <._null._> *This is part of why the compiler is fast and executable speed is predictable

09:41 <octachron> compiler optimisations that you can reasonably expects are constant propagations and a limited amount of inlining. Inlining is better with flambda, and this aspect will be improved further with flambda2.

09:44 <octachron> But all optimisations currently preserve the semantics of untyped OCaml which impose that it not possible to change the order of side-effects. And with asynchronous exceptions, an allocation is a side-effect.

09:48 <octachron> So proably the take away is that the code that you write is mostly the code that is run with the optimisers trying to optimise details that you didn't write like the call stacks, the handling of closure environment, ... .

16:37 <greenbagels> octachron: i see, thanks!

20:57 <Anarchos> what happens to branch 4.14.2 ? The LTS is 4.14.1...

20:58 <discocaml> <undu> Probably preparing the release 4.14.2?

21:59 <octachron> The LTS branch is 4.14. There will be a release of 4.14.2 in the beginning of 2024.

22:44 <dh`> I do have a real lwt question, though. it seems that asserting or generating other exceptions in lwt contexts causes the exceptions to evaporate silently

22:44 <dh`> what's the right way to prevent that?