06:04 <discocaml> <profmonkey07> I quit a project because I couldnt figure out what the problem was for like a week just to find out that I needed to count [1;2;3;4] as being the same as [4;3;2;1] basically

06:04 <discocaml> <profmonkey07> bruhhhhh

06:04 <discocaml> <profmonkey07> and then spend an hour debugging because 2 variabls were swapped

06:10 <bartholin> debugging can be frustrating

10:15 <discocaml> <johnkraiven> I have recently stumbled over this OCaml syntax and I was wondering if someone can help me trace its documentation, for I don't even know per se how the thing is called, my assumption is that it is a form of literal enumeration, but I am uncertain whether that's the case or not

10:16 <discocaml> <johnkraiven> I have recently stumbled over this OCaml syntax and I was wondering if someone can help me trace its documentation, for I don't even know per se how the thing is called, my assumption is that it is a form of literal enumeration, but I am uncertain whether that's the case or not

10:16 <discocaml> <johnkraiven> ```ocaml

10:16 <discocaml> <johnkraiven> type t = [ `A | `B ]

10:16 <discocaml> <johnkraiven> ```

10:17 <discocaml> <johnkraiven> and what I find more mistifying is what the type of a variable of type t is that being ```let a = `A;; │~

10:17 <discocaml> <johnkraiven> val a : [> `A ] = `A```

10:17 <discocaml> <johnkraiven> and what I find more mistifying is what the type of a variable of type t is that being ```ocaml let a = `A;; │~

10:17 <discocaml> <johnkraiven> val a : [> `A ] = `A```

10:18 <discocaml> <johnkraiven> and what I find more mistifying is what the type of a variable of type t is that being

10:18 <discocaml> <johnkraiven> ```ocaml

10:18 <discocaml> <johnkraiven> let a = `A;; │~

10:18 <discocaml> <johnkraiven> val a : [> `A ] = `A

10:18 <discocaml> <johnkraiven> ```

10:18 <discocaml> <johnkraiven> and what I find more mistifying is what the type of a variable of type t is that being

10:18 <discocaml> <johnkraiven> ```ocaml

10:18 <discocaml> <johnkraiven> let a = `A;; │~

10:18 <discocaml> <johnkraiven> val a : [> `A ] = `A

10:18 <discocaml> <johnkraiven> ```

10:18 <discocaml> <leviroth> It’s called a polymorphic variant.

10:20 <discocaml> <johnkraiven> thanks!

10:26 <discocaml> <getzapped.> are there any builtins to flatten 'a option list into 'a list option

10:27 <discocaml> <getzapped.> is there a builtin sequence function to flatten 'a option list into 'a list option

10:31 <discocaml> <getzapped.> is there a builtin sequence function to flatten an 'a applicative list into 'a list applicative for applicatives like result or option

10:32 <rustyne> `List.filter_map Fun.id` has the type `'a option list -> 'a list`, if that helps

10:36 <discocaml> <90857467> Hello, my name is Ksenia. I offer account rental services on Upwork, Freelancer, Fiverr, LinkedIn and Workana at favorable prices. Feel free to contact me so we can discuss your needs 🙌

10:38 <discocaml> <getzapped.> This just discards options instead of short circuiting, unfortunately. Not a pain to write manually tho.

10:39 <discocaml> <getzapped.> This just discards nones instead of short circuiting, unfortunately. Not a pain to write manually tho.

11:53 <discocaml> <limp.biskit> reversed lists tripped me up too coming from languages that all support push

12:18 <discocaml> <leviroth> Thanks @anmonteiro , setting up and running nix was indeed pretty straightforward

12:32 <discocaml> <otini_> sorry what’s the expected semantics? And if it’s obvious to you just given the fact that the elements are applicatives, I’d be curious to know why

12:40 <rustyne> otini_: it is natural to define in Haskell because the semantics there is a combination of the type classes involved

12:40 <rustyne> those implicit parameters would have to be made explicit in OCaml

12:41 <rustyne> (combination of the type class instances, I should have said)

12:42 <rustyne> see for instance https://hackage.haskell.org/package/base-4.20.0.1/docs/Data-Traversable.html

12:50 <discocaml> <otini_> Ah I hadn’t read the question closely enough

12:59 <discocaml> <otini_> I think the short-circuiting in the Haskell definition relies on laziness, as well as the general efficiency of the function

13:00 <discocaml> <otini_> which in addition to the absence of type classes—which makes that kind of generic functions heavier because you need a functor—is another reason why it would not necessarily be desirable to have it in the stdlib

14:23 <discocaml> <arthurmiiengineering> hallo!

15:01 <discocaml> <gooby_clown> Does anyone work with Melange? I was wondering what the normal project structure would be. The generated Melange project is its own dune project, and then I have my backend as another project. I put this under a single `dune-workspace`, and now I was wondering, what should I do to, for example, run both projects at the same time? I could just run them in a shell script, but was wondering if there's a dune way

15:08 <discocaml> <gooby_clown> Actually I removed the workspace file, makes the Melange build fail

15:20 <discocaml> <otini_> hi

16:04 <discocaml> <ethanrange> Is compiling the OCaml 4.14.1 compiler from source supported on Apple M1, either natively or by using x86 with `env /usr/bin/arch -x86_64 /bin/zsh`? I'm running into errors about inconsistent architectures either way

16:05 <discocaml> <ethanrange> Particularly `Error: The files asmcomp/arch.cmi and /mach.cmi make inconsistent assumptions over interface Arch`

16:10 <rustyne> It should build yes, at least CI on the 4.14 runs also on arm64 mac

16:11 <discocaml> <ethanrange> Hm very odd, I'll give it another run with absolutely minimal flags and options

16:12 <rustyne> “inconsistent assumptions” errors are usually from files left over from compilations with a different configuration or such like

16:13 <rustyne> `make distclean; ./configure ...; make -j` might be the best way to go :-)

16:19 <discocaml> <ethanrange> Ooh is `make distclean` a superset of `make clean`?

16:21 <rustyne> indeed

16:24 <discocaml> <ethanrange> I think I managed to get a successful build without `distclean`, but I'll keep that one for future use. Thanks!

16:33 <discocaml> <ethanrange> Argh nevermind - it looks like it's an issue with the specific modified OCaml compiler I'm trying to build (MetaOCaml)

16:34 <discocaml> <ethanrange> Building the 4.14.1 release works fine, but after applying the MetaOCaml patches, the error appears ```Error: The files asmcomp/arch.cmi and asmcomp/emitenv.cmi make inconsistent assumptions over interface Arch

16:34 <discocaml> <ethanrange> ```

16:34 <discocaml> <ethanrange> Thanks for the help anyway - I'll try debugging this

16:35 <rustyne> you’re welcome

16:53 <companion_cube> … is there no docs at all for `[@@deriving_inline]`? :/

16:53 <companion_cube> can't find a thing!

16:57 <discocaml> <holmdunc> Replies to this thread has some info https://discuss.ocaml.org/t/ocaml-platform-newsletter-march-may-2024/14765

16:58 <rustyne> https://ocaml.org/p/ppxlib/latest/doc/writing-ppxs.html#inlining-transformations

17:00 <companion_cube> oh well, it doesn't work anyway

17:02 <companion_cube> (ppx_deriving_yojson emits non compiling garbage)

17:03 <rustyne> you wondered about deriving_inline only to have a look at the generated code? if yes, do you know dune show pp?

17:03 <companion_cube> no no

17:03 <companion_cube> but it generates code that doesn't compile, so..

17:20 <discocaml> <ethanrange> `make bootstrap` for anyone who comes across this in the future

17:31 <discocaml> <anmonteiro> Will need a bit more info. How did the melange build fail after you removed the workspace file?

17:45 <discocaml> <gooby_clown> Nono it was the other way round, it succeeded only after removing it, because with it `dune build` goes up a directory to the workspace file, whereas the dune file for Melange has like `../../node_modules/...` which fails with the automatic change of directory

17:45 <discocaml> <gooby_clown> But anyways that wasn't what I wanted to ask about, mostly just how we are supposed to structure codebases involving a Melange project as well as some backend ones

17:46 <discocaml> <anmonteiro> It’s really up to you

17:47 <discocaml> <anmonteiro> Some frameworks like nextjs dictate some structure, but otherwise you’re free to use whatever folders you’d like

17:48 <discocaml> <gooby_clown> A okok I see, thanks ^^

18:31 <discocaml> <limp.biskit> eio makes me go ugh

18:31 <discocaml> <limp.biskit> what's resource management? i really wish somebody would've worked it out beforehand

18:52 <dh`> (I mean not in the kernel)

18:52 <dh`> oops

21:00 <discocaml> <sim642> deriving_inline yojson producing non-compiling code sounds like a ppxlib issue. Because under the hood the parsetree should be fine since it works for normal deriving

21:02 <companion_cube> yeah it makes a bunch of extraneous `let _ = _`

21:02 <discocaml> <limp.biskit> does ppx_yojson_conv work?

21:04 <companion_cube> no idea, haven't tried

21:05 <discocaml> <limp.biskit> apparently it’s implementation is a little more sane than deriving, at least from what jst say

21:06 <companion_cube> ppx_deriving has been upgraded so I'm assuming it's on par, idk