00:03 <discocaml> <regularspatula> Oh yeah. base Or_error uses lazy internally …I guess serialization and comparisons will need to be locked if you do something weird like capture some mutable state when creating them

00:21 <companion_cube> Lazy and serialization already don't play too well :D. At least Marshall.

15:40 <discocaml> <contextfreebeer> how do you handle creating artifacts that are to be used at *runtime* with Dune? e.g. for a compiler using Dune to compile the runtime that you will link against. You can hardcode the path of course but how do you solve this properly?

15:44 <discocaml> <contextfreebeer> by "hardcode the path" I mean specify the path to the object file in the _build directory

15:59 <discocaml> <yawaramin> you can read the path from an environment variable

16:05 <discocaml> <contextfreebeer> ig

17:36 <companion_cube> I'd like to group some common cmdliner options in a record, and have a parser for this record that's shared in multiple commands

17:37 <companion_cube> anyone knows if it's possible? I only see individual flags in cmdliner :/

18:30 <discocaml> <smondet> @companion_cube you can do that with `Cmdliner.Term.t` values but not for parses AFAIK (arg parsers are for individual options)

18:30 <discocaml> <smondet> @companion_cube you can do that with `Cmdliner.Term.t` values but not for parsers AFAIK (arg parsers are for individual options)

18:36 <companion_cube> but I didn't see a way to use a term in another term, did I miss it?

18:38 <discocaml> <andreypopp> via $

18:38 <discocaml> <andreypopp> f $ arg1 $ arg2

18:45 <companion_cube> hu, ok

18:45 <companion_cube> thought that didn't work for some reason

18:48 <discocaml> <gabyfle> Is OCaml generally faster when manipulating mutable data structures or immutable data structures ?

18:50 <discocaml> <gabyfle> I had the choice and I always prefer using immutable ones so my code is always "reconstructing" types (idk if this take makes sense). For example, all my functions will have a prototype that looks like t -> ... -> t. And I'm wondering if this is a bad habit or not, or if using mutable types instead of immutable ones would make my program overall faster

18:59 <discocaml> <contextfreebeer> it can be slower in some cases, but sometimes the change to the asymptotics or the removal of big constant factors makes that irrelevant

19:00 <discocaml> <contextfreebeer> mutable access isn't the same as in imperative languages due to the write barrier, as I understand it, but I have also observed that making things mutable indiscriminately can pessimize the performance

19:04 <discocaml> <gabyfle> Ok, because I'm actually working on a virtual machine for a language of my own and I for the bytecode execution, the `vm` state is actually immutable and is being reconstructed each time an operation is made, so I was wondering if that could hit the performances doing this instead of just mutating values inside the state type

19:05 <discocaml> <contextfreebeer> it's exactly that kind of thing which tends to not be faster, IME, but it probably depends on the specifics of your code, you could try measuring both ways

19:05 <discocaml> <contextfreebeer> in general I wouldn't worry about these questions unless you have proof that this is what's slowing you down

19:06 <discocaml> <gabyfle> No i'm actually pretty sure this is not what's slowing me down

19:06 <discocaml> <gabyfle> I was just wondering if any of those method to build code is faster than the other

19:08 <discocaml> <contextfreebeer> normally records like that are just a bunch of pointers, so you're copying like maybe a few bytes each time? it's nothing. whereas mutating directly might need to go through a function call so the GC is aware of what's going on

19:09 <discocaml> <contextfreebeer> so it will probably usually be slower, but you should use mutation if you want mutable semantics or the shape of your program is such that by doing mutation you can bypss a lot of work, it's a trade off

19:56 <discocaml> <limp.biskit> is`with` faster than mutable fields?

20:09 <discocaml> <octachron> It can be faster.