01:40 <discocaml> <deepspacejohn> Also “generative” functors are able to create modules with no input module, specifically for creating new types.

01:41 <dh`> hmm this seems broken

01:41 <dh`> % dune --version

01:41 <dh`> n/a

01:42 <discocaml> <mbacarella> functors are monads in which the bind operation degenerates into a lifting of pure morphisms, such that the monadic structure collapses into a single-layer context application without requiring a join to resolve nested contexts.

01:42 <discocaml> <mbacarella> what's the problem?

02:12 <discocaml> <darrenldl> is it correct that in order to statically link C dependencies, the i need to write C stubs for ctypes instead of using the dynamic lookups?

02:12 <dh`> depends what you're statically linking

02:13 <discocaml> <darrenldl> trying to link either zstd lib or zlib

02:13 <dh`> I would expect that everything in ctypes comes from libc, so as long as you don't link libc statically there shouldn't be problems

02:13 <discocaml> <darrenldl> and deciding between camlzip and zstd package, latter of which doesn't use C stubs, and I can't remember if that caused issue for me in the past

02:14 <discocaml> <darrenldl> yeah...i'm trying to link on alpine with musl

02:17 <dh`> I remember using ctypes for something or other at some point but I can't remember what and it wasn't very intensive

02:17 <dh`> so mostly I dunno but I can tell you things about dynamic linking

02:17 <dh`> (mostly things that will make your hair curl, soundness isn't even a remote consideration)

05:10 <discocaml> <diligentclerk> I know you're joking around but OCaml module functors are named by loose analogy to category-theoretic functors rather than by formal correspondence so it can be confusing to conflate them

05:11 <discocaml> <diligentclerk> ```ocaml

05:11 <discocaml> <diligentclerk> module type S =

05:11 <discocaml> <diligentclerk> type t

05:11 <discocaml> <diligentclerk> val s : (t -> t) -> t

05:11 <discocaml> <diligentclerk> end

05:11 <discocaml> <diligentclerk> ```

05:11 <discocaml> <diligentclerk> I think this should be an example of a module type where there is not a sensible way to define a category of modules and module homomorphisms

05:13 <discocaml> <diligentclerk> Also yeah that is some comically confusing prose 😄

06:39 <discocaml> <iamjcchan> is there a production ready http framework/server for ocaml 5?

10:47 <discocaml> <lecondorduplateau> there is <https://github.com/robur-coop/httpcats>

10:51 <discocaml> <lecondorduplateau> even its not really a "framework"

10:51 <discocaml> <lecondorduplateau> rather a library

11:19 <discocaml> <dinosaure> We added recently the hack into `ocaml-tar` but I see, from my experience:

11:19 <discocaml> <dinosaure> 1) It's really unusual for other users to be faced with this design (and therefore not easy to reappropriate).

11:19 <discocaml> <dinosaure> 2) The syntax becomes rather cumbersome (between projection/injection and monads).

11:19 <discocaml> <dinosaure> 3) As @octachron mentioned, it's still a fairly fragile trick (particularly because of the `Obj.magic`).

14:27 <companion_cube> @iamjcchan people often use opium or dream

16:05 <discocaml> <yawaramin> another library https://github.com/anmonteiro/piaf/blob/master/examples/eio/eio_multidomain_server.ml

16:10 <companion_cube> Didn't realize piaf was also server side

16:18 <discocaml> <yawaramin> yeah the request and response types are the same so it's symmetrical

16:23 <companion_cube> Same as dream heh

16:28 <discocaml> <yawaramin> sorry i meant specifically that the server and client have the same request and response types. but you're right about Dream using the same base 'message' type for both. plus the Hyper client library also has the property of using the same request and response types that Dream does

22:37 <dh`> is one supposed to recompile everything if going from 4.12.1 to 4.12.2?

22:37 <dh`> er

22:37 <dh`> 4.14.1 to 4.14.2