09:28 <hanker> Is there a way to get conditional compilation in OCaml? Like there is with `#ifdef DEBUG` in C

09:39 <discocaml> <contificate> Can do rules in dune to generate a module dynamically

09:44 <zor> hanker: not built-in, I don't think, but there's 3rd party things, e.g. https://github.com/ocaml-community/cppo

09:53 <hanker> > hanker: not built-in, I don't think, but there's 3rd party things, e.g. https://github.com/ocaml-community/cppo

09:53 <hanker> i already have a ppx :/ sadly it seems cppo and ppxs aren't compatible in a single file

10:27 <zor> I haven't used it, but it does claim to work with ppxs, so there might be a way...

10:49 <discocaml> <otini_> there is https://ocaml.org/p/ppx_optcomp/latest

16:07 <hanker> > <otini_> there is https://ocaml.org/p/ppx_optcomp/latest

16:07 <hanker> Is there a way to make it dependent on Dune profiles?

16:44 <discocaml> <vortex1000> Hi , i am Krenar from Albania , i am 23 year old and i have studied computer science . If you are interested to buy a JetBrains licence for 35$ please dm me 🙂 .i can give you all the info you need in dm's if you are interested if not sorry . My discord is vortex1000

16:44 <discocaml> <vortex1000> i can even give you the licence first if you add me on facebook

17:16 <discocaml> <deepspacejohn> Interesting: https://blog.janestreet.com/introducing-oxcaml/

17:32 <discocaml> <shadowkestrel> yippeeeee i've been wanting to play with jane street's extensions for a while now, nice to have a more 'official'-feeling way to get them as an outsider

17:39 <discocaml> <jwcb_71795> I had trouble getting some 3rd-party packages (odoc, eio) to build on a switch with that version

17:42 <discocaml> <deepspacejohn> the whole project looks cool but I personally just care about the minor "quality of life" stuff, haha. At least two of them (labelled tuples and immutable arrays) are on track to be in 5.4!

17:43 <discocaml> <sim642> Heh, the date on that post is tomorrow

17:45 <discocaml> <deepspacejohn> literally OCaml from the future.

20:37 <discocaml> <aguluman> I guess this was the premise to the OxCaml story that dropped today.

20:37 <discocaml> <aguluman> https://blog.janestreet.com/oxidizing-ocaml-locality/

21:06 <discocaml> <shadowkestrel> they've been working on these things internally for a while, and while their forks were always publically accessible they didn't advertise that fact much

21:28 <discocaml> <uberpyro181> i wish the name was a little more different

21:36 <discocaml> <undu> I think oxymel would have been very fitting https://en.wikipedia.org/wiki/Oxymel

21:48 <dh`> in what way is making a public fork not hostile?

21:51 <dh`> also, > Fearless concurrency: Writing correct concurrent programs is notoriously difficult. OxCaml includes additions to the type system to statically rule out data races.

21:51 <dh`> I would say clearly they aren't intending to be taken seriously, except I expect they are

21:51 <discocaml> <undu> they do the fork to iterate on the concepts, and are slowly upstreming them, a couple of features have already been upstreamed

21:52 <discocaml> <undu> see https://oxcaml.org/documentation/

21:52 <companion_cube> dh`: why is a fork necessarily hostile?

22:06 <discocaml> <yawaramin> forks aren't hostile; people are. and as far as i can tell the Jane Street people have a long-standing, cordial relationship with the OCaml core team

22:14 <discocaml> <froyo> definitely not hostile, no question about that. this is a public development branch with the sole intention of upstreaming

22:14 <discocaml> <yawaramin> yeah. eg look at this: https://discuss.ocaml.org/t/record-element-types-must-have-a-representable-layout/16807/6?u=yawaramin - this shows a mutually beneficial relationship

22:15 <discocaml> <froyo> it is cordial and polite _soft-power_ though...

22:15 <discocaml> <froyo> one can't help but wonder what happens if upstream maintainers are unhappy with one of the features and can't see it integrating well with the language but janestreet has already invested a lot in it.

22:16 <discocaml> <froyo> do they explain somewhere what their protocol with that would be?

22:17 <discocaml> <froyo> janestreet releases a lot of internally developed libraries to the public. if they decide to maintain an internal feature they invested in it, that means these libraries will have to make some kind of a choice to play nicely with upstream ocaml

22:17 <discocaml> <froyo> today that means ppxes and watching out for subtle runtime differences

22:20 <discocaml> <polyml> if ocaml doesn't plan on upstreaming stack allocations or unboxed types then it makes sense for jane street to put a pr campaign behind oxcaml since that would make it useful enough to distinguish it from normal ocaml

22:23 <companion_cube> It'll be a real fork the day they have their own opam repo I think, and even then

22:23 <companion_cube> Sometimes fork end up merging back, eg iojs