03:34 <discocaml> <darrenldl> is there a legitimate use of spurious wakeups in condition var? why do we still have to check the condition in a loop to this day?

03:46 <companion_cube> it's not a feature

03:46 <companion_cube> it's an implementation detail

03:59 <discocaml> <darrenldl> why must API expose said detail though?

04:00 <discocaml> <darrenldl> if they anticipate people to always put it in a loop when using the api, why not just do the loop underneath the api?

04:00 <discocaml> <darrenldl> (at least for eio condition)

04:23 <companion_cube> oh, in eio

04:23 <companion_cube> no idea

04:27 <discocaml> <darrenldl> i mean even outside of eio, it didn't make sense to me why it landed as an api

04:27 <companion_cube> it's just how it works

04:27 <companion_cube> many threads might be woken up and only one will get the thing

04:27 <companion_cube> (e.g the element in a blocking queue)

04:27 <companion_cube> you have to have the loop

04:31 <discocaml> <darrenldl> right, but there's no fundamental reason why the loop cannot be within the code underneath API, and the justification by David R. Butenhof reads a bit silly

04:31 <discocaml> <darrenldl> > We followed that intent with several levels of justification. The first was that

04:31 <discocaml> <darrenldl> > "religiously" using a loop protects the application against its own imperfect

04:31 <discocaml> <darrenldl> > coding practices. The second was that it wasn't difficult to abstractly imagine

04:31 <discocaml> <darrenldl> > machines and implementation code that could exploit this requirement to improve

04:31 <discocaml> <darrenldl> > the performance of average condition wait operations through optimizing the

04:31 <discocaml> <darrenldl> > synchronization mechanisms.

04:32 <discocaml> <darrenldl> <https://groups.google.com/group/comp.programming.threads/browse_frm/thread/327958c427ea978c?hl=de&pli=1>

04:33 <discocaml> <darrenldl> The preceding paragraph:

04:33 <discocaml> <darrenldl> >

04:33 <discocaml> <darrenldl> > The intent was to force correct/robust code by requiring predicate loops. This was

04:33 <discocaml> <darrenldl> > driven by the provably correct academic contingent among the "core threadies" in

04:33 <discocaml> <darrenldl> > the working group, though I don't think anyone really disagreed with the intent

04:33 <discocaml> <darrenldl> > once they understood what it meant.

04:33 <discocaml> <darrenldl> anyway, i'm not sure what i'm looking for in this, whatever

11:27 <discocaml> <bluddy5> If I want to re-export a type's constructors from a different module, do I need to rewrite those constructors?

11:27 <discocaml> <bluddy5> Suppose A has `type foo = Foo | Bar | Baz` and I want everyone to use B as the access point to `foo`. B has `type foo = A.foo`. If I want to allow other modules to use `Foo | Bar | Baz` while only accessing `B`, do I need to recreate the constructors?

11:28 <discocaml> <____aaaaaaaaaaaa> What is Ocamel

11:28 <discocaml> <____aaaaaaaaaaaa> ive seen it around recently

11:33 <discocaml> <Kali> OCaml is a functional, object-oriented, and imperative programming language which focuses on expressivity while still being safe and easy to write

11:36 <discocaml> <froyo> yes

11:38 <discocaml> <froyo> in reply to Bluddy

11:38 <discocaml> <bluddy5> ok so the only easy solution is ppx_import. Thanks.

11:41 <discocaml> <froyo> yes or to flatten your modules a bit

11:43 <discocaml> <froyo> so that you don't have to do this reexporting often

11:48 <discocaml> <leviroth> >If I want to allow other modules to use Foo | Bar | Baz while only accessing B, do I need to recreate the constructors?

11:48 <discocaml> <leviroth>

11:48 <discocaml> <leviroth> Strictly speaking they should be able to *use* the constructors through type-directed disambiguation, but of course it's often more ergonomic to re-export the constructors.

12:16 <Xogium> hi folks :) hopefully quick question today. I've installed an opam switch that had been created with opam switch export using --freeze and --full. Is there any way to force opam to update the pinned git packages to their latest commit without manually unpinning and pinning them again ?

15:42 <discocaml> <flyinfoxtrot> anyone know is it possible to make https request using cohttp-eio?

21:34 <discocaml> <anmonteiro> this doesn't seem like the "only easy solution"

21:34 <discocaml> <anmonteiro> an easier solution is copy pasting