02:04 <companion_cube> ohh, a virtual class's *signature* can inherit a class type

02:04 <companion_cube> ok that's good

03:17 <companion_cube> also: interesting how imperative code still _is_ faster than recursive functions, for some things

03:17 <companion_cube> I guess OCaml is better at avoiding boxing this way

11:24 <toastal> Not sure how to ask… what’s the difference between type Foo = Bar | Baz & type Foo = [ `Bar | `Baz ]?

11:30 <Fardale> The first one define a variant type (more in this section https://v2.ocaml.org/manual/coreexamples.html#s%3Adatatypes), the second one uses polymorphic variants (https://v2.ocaml.org/manual/polyvariant.html)

11:32 <Fardale> One think you can do with Polymorphic variant is subtyping. In your exemple Foo is a subtype of [`Bar | `Baz | `Toto]

11:32 <Fardale> For more difference, you will have to wait for people with more experience with them.

11:48 <discocaml> <dinosaure> the first advantage of polymorphic variants is that you don't need to express `type t = [ 'Foo | 'Bar ]` to start to use them. You can directly say: `val eval : state -> [ 'Continue | 'Discontinue ]` where, with a simple ADT, you must do `type t = Continue | Discontinue ;; val eval : state -> t`

11:50 <discocaml> <dinosaure> the second advantage is that you can _pattern-match_ a subset of a set of polymorphic variants such as `type rgb = [ 'Red | 'Green | 'Blue ] and color = [ rgb | 'Yellow | 'Magenta ]` and `match color with #rgb as rgb_color -> ... | other_color -> ...`

11:52 <discocaml> <dinosaure> this is why we talk about _sub_-typing. You can manipulate a subset of all possibilities if you want 🙂

12:16 <discocaml> <xavierm02_> Is there some point to splitting a huge program (say a compiler) into many dune libraries (say one par pass)?

12:16 <discocaml> <xavierm02_> Is there some point to splitting a huge program (say a compiler) into many dune libraries (say one per pass)?

12:53 <discocaml> <Kali> it is `, not '

12:53 <discocaml> <Kali> you can put ` in inline code by using two instead of one on either side

12:54 <discocaml> <dinosaure> did not know 🙂

12:54 <discocaml> <Kali> `` `Like `This``

12:54 <discocaml> <Kali> ```

12:54 <discocaml> <Kali> `` `Like `This``

12:54 <discocaml> <Kali> ```

13:43 <companion_cube> on 5.0, we currently have no way to measure what takes space in the heap, do we?

13:50 <discocaml> <deepspacejohn> I'm not sure if there's a point beyond just being a way to organize your modules. It makes the build slightly more complex but if you have a lot of modules then it may be worth it?

13:51 <companion_cube> yeah it's pretty useful to split into many dune libraries imho

13:51 <companion_cube> you get better control of public/private stuff, dependencies, and you can keep each library a reasonable size

13:52 <discocaml> <deepspacejohn> oh yeah, those are all good advantages

14:09 <discocaml> <xavierm02_> Ok. Thanks!

14:12 <companion_cube> octachron: has anyone seen, with 5.0, situations where htop reports gigabytes of memory used, but GC stats return small major heaps (like, 20MB)?

14:12 <companion_cube> that's in presence of significant C bindings, but these are a library, not mine

14:13 <companion_cube> like, the C objects should be collected, and maybe they're not?

14:14 <Fardale> An other advantage of splitting in libraries using dune is that in the dev profile, dune will not recompile everything just the library that changes and what depends on them.

14:19 <discocaml> <sim642> That also happens within a single library between modules

14:20 <octachron> companion_cube, the GC should still report the memory used by C bindings (if they are recorded correctly)

14:20 <companion_cube> they're not, since it's far too limited for that afaict?

14:20 <companion_cube> I mean, you _can_ speak of the size of a bigarray or such, but nothing more complicated than that, can you?

14:20 <discocaml> <flyinfoxtrot> does ocaml have defined behavior for order of operations here? will it always print `world`?

14:20 <discocaml> <flyinfoxtrot>

14:21 <discocaml> <flyinfoxtrot> ```

14:21 <discocaml> <flyinfoxtrot> let _ =

14:21 <discocaml> <flyinfoxtrot> ( print_endline "hello",

14:21 <discocaml> <flyinfoxtrot> failwith "bye",

14:21 <discocaml> <flyinfoxtrot> print_endline "world" )

14:21 <discocaml> <flyinfoxtrot> ```

14:21 <companion_cube> please don't :D

14:21 <companion_cube> don't rely on this ever ever

14:21 <octachron> I don't remember a similar issue, but did you try with 5.1 ?

14:22 <octachron> I am tempted to have a chaos patch to the compiler that randomize such patterns.

14:22 <companion_cube> I'm compiling 5.1 right now :D

14:22 <companion_cube> 5.1~rc3, that is

14:23 <companion_cube> octachron: but generally, the C API doesn't allow one to say how big a C value is, except for a fixed int at creation, right?

14:24 <octachron> companion_cube, yes, FFI only allow you to give a size hint to the GC.

14:25 <companion_cube> yeah.

14:25 <companion_cube> so here, the values are Z3 solvers, and they can be arbitrarily big, and grow, etc. :D

14:26 <octachron> Indeed, you are right, the GC cannot report the C heap size.

14:27 <companion_cube> I tried using jemalloc but it doesn't help :/

14:39 <companion_cube> seems to be same on 5.1

14:45 <companion_cube> (I guess statmemprof is supposed to work again, but if it doesn't seen the C memory it won't help)

14:58 <octachron> statmemprof is planned for 5.2, there are just less bugs in the 5.1 runtime.

14:59 <companion_cube> oooh ok

15:00 <companion_cube> exciting times anyway :)

15:00 <octachron> And I imagine that the same code behaves in 4.14 ?

15:00 <companion_cube> I haven't tested it on 4.14, I'm not sure it compiles (there are some deps on compiler-libs, etc. …)

15:01 <octachron> 4.14 or any 4.x version

15:02 <companion_cube> I'll have to try yeah

15:02 <companion_cube> (I don't think compiler-libs changed that much between 4.14 and 5.0…?)

15:02 <octachron> There were no changes at all

15:03 <companion_cube> nice. I might try it later today then, I think my deps are not 5.0-only (not even moonpool!)

15:03 <octachron> (aka 5.0 is probably the favourite release of the merlin and ppxlib team since a ... long time)

15:50 <theblatte> companion_cube: re: lots of resident memory but small heaps according to the GC, maybe that's due to the fact 5.0 doesn't give back memory when the heap shrinks?

15:50 <theblatte> aka https://github.com/ocaml/ocaml/pull/12193

15:55 <discocaml> <leviroth> Oh that’s why my memory usage got worse…

16:05 <companion_cube> theblatte: it can't be only that, because GC stats tell me that the max heap size was 100MB

16:05 <companion_cube> but yeah

21:21 <discocaml> <cemerick> @dinosaure I've been reading miou's docs a bunch, and I think it's clicked for me. Do I have it right that if we _quantize_ our long-running, CPU-bound tasks (e.g. maybe each `tick` of a solver), then it should be pretty trivial to parallelize those tasks in a fine-grained way across multiple domains in a way that interrupting/cancelling them sort of falls out of it all quite effortlessly?

21:27 <discocaml> <cemerick> that's the sort of thing I figured I'd end up doing "manually" so to speak, just to be able to interrupt/limit long-running (or runaway) computations; but ofc it'd be so much better to plug into a more purpose-built set of abstractions

21:40 <companion_cube> what does "quantize" mean in this context?