00:38 <discocaml> <masterbuilder> probably not, it's not a terribly difficult language but there will be a learning curve

00:43 <discocaml> <cemerick> whew, until today, I somehow thought Lwt.bind implicitly `pause`d, i.e. allowed other pending to run if necessary 🤡

00:44 <discocaml> <cemerick> It's distressing that I've been holding such a misconception while still seeming to knock along productively

00:59 <companion_cube> iirc there's lwt.yield

01:02 <discocaml> <regularspatula> the Async lib works that way right?

01:03 <companion_cube> I think so

08:41 <discocaml> <JM> There was some discussions on this a while back in discord

08:42 <discocaml> <JM> https://discuss.ocaml.org/t/multicore-async-and-lwt/2687/13

12:46 <discocaml> <cemerick> companion_cube: `yield` is in Lwt_unix, and is just an alias for `Lwt.pause`

12:48 <discocaml> <cemerick> sorry, not an alias, but a vestigial predecessor

13:01 <discocaml> <Ada> i write in both and unless you have a background in functional programming golang is easier for sure

13:01 <discocaml> <Ada> go is a really simple language, for better or for worse

13:01 <discocaml> <Ada> ocaml is the opposite

13:02 <discocaml> <Ada> i'd say its worth learning ocaml tho, it's a very interesting lang and now that concurrency support is picking up it's as practical as go

13:08 <discocaml> <xavierm02_> Is there a parser library that allows defining several grammars and to decide how to combine them at runtime?

13:10 <discocaml> <xavierm02_> With backtracking

13:38 <discocaml> <xavierm02_> pacomb looks like it might work, I'll try it

14:05 <discocaml> <xavierm02_> The order of libraries in the dune stanza is important 😮

14:06 <discocaml> <cemerick> angstrom is a quality parser combinator library, and pretty heavily used

14:10 <discocaml> <cemerick> I....don't think that's true?

14:16 <discocaml> <xavierm02_> If I swap `unix` and `pacomb`, I get ```File "_none_", line 1:

14:16 <discocaml> <xavierm02_> Error: No implementations provided for the following modules:

14:16 <discocaml> <xavierm02_> Unix referenced from /home/user/.opam/default/lib/pacomb/pacomb.cmxa(Pacomb__Input),

14:16 <discocaml> <xavierm02_> /home/user/.opam/default/lib/pacomb/pacomb.cmxa(Pacomb__Pos)```

14:16 <discocaml> <xavierm02_> But I have Core, staged ppxs etc., so it might be an interaction with something else

14:53 <discocaml> <xavierm02_> Nevermind, it also works with a basically empty project

14:57 <discocaml> <xavierm02_> Nevermind, I could reproduce this bug (?) in a basically empty project

15:12 <discocaml> <anmonteiro> You need to add the unix library

15:28 <discocaml> <xavierm02_> https://pastebin.com/rxR0naVi

15:30 <discocaml> <xavierm02_> Running this script with bash gives me the "No implementations" error, while the same script with the pacomb and unix libraries swapped does not

15:37 <discocaml> <sim642> Sounds like a pacomb bug that it misses a dependency maybe

15:38 <discocaml> <amaro_amaro> Windows (or Cygwin?) question: it seems that, when loading `.cmxs` files under Cygwin, the execute bit of the file must be set, otherwise I get a `Permission denied` error. On Linux, this is not necessary, even if for some reason *most* `.cmxs` installed in my opam's `lib` directory do have the bit set.

15:38 <discocaml> <amaro_amaro>

15:38 <discocaml> <amaro_amaro> But a few of them don't, which causes all kinds of unexpected issues in Cygwin... for instance, `lib/ocaml/nums.cmxs` does *not* have its bit set. But `str.cmxs` and `unix.cmxs`, in the same directory, do. A few libraries (`logs`, `bos`, `rresult`, `why3`) don't have it, but almost everyone else does (I guess `dune`-based installations have it set by default).

15:38 <discocaml> <amaro_amaro>

15:38 <discocaml> <amaro_amaro> Is this supposed to be uniform? Is this difference in behavior expected, or acknowledged, when under Cygwin? Is there something we could do to make sure things become more normalized?

15:42 <discocaml> <xavierm02_> @sim642 Ah right. I just checked, and unix is listed as a dependency for tests and benchmarks but nowhere else

16:26 <discocaml> <kakadu18> Have you encountered a situation, where `ppx_expect` replaces `{|...|}` by `"..."` on promotion? How to prevent that from happening?

17:33 <discocaml> <sim642> Maybe a bug? I think the parsetree should distinguish them but maybe ppx_expect forgets

20:19 <discocaml> <agarwal1975> These could be deleted for now. There a couple of issues. Dune and opam need to support writing and reading those files from a subdirectory. The purpose of them is that we are considering releasing 300 packages to opam. Then end users wouldn't have to depend on the code generator, but just use the published packages. Of course, that is a lot of packages, so we also want to talk to the opam team before doing anything like that.

20:20 <discocaml> <agarwal1975> It is considered better practice to have one findlib library per opam package.

20:21 <discocaml> <agarwal1975> Some of the ml files that are generated are huge. The ocaml compiler ends up having trouble. We have a solution in mind, but it is not yet implemented.

20:22 <discocaml> <agarwal1975> That is indeed the case. You are not locked in to cohttp nor any particular concurrency framework. The awsm-async and awsm-lwt packages are minimal. You could implement an alternate yourself. The core generated code makes no mention of cohttp nor async or lwt.

20:24 <discocaml> <anmonteiro> now I'm interested. I saw `cohttp` in the `awsm` dependencies and noped out. I suppose that's only for the code generator

20:24 <discocaml> <sim642> 300 packages with versions of each to come is a lot. I wouldn't be surprised if it started affecting opam solver performance at one point

20:27 <discocaml> <agarwal1975> The generated code is supposed to have zero dependencies, but we haven't quite achieved that. The coder generator's dependencies could perhaps be reduced also, but we don't particularly care about that. If we publish the generated packages, then it shouldn't matter. But yes, publishing 300 packages is not something we can do without discussion with the broader community.

20:27 <discocaml> <agarwal1975> The generated code is supposed to have zero dependencies, but we haven't quite achieved that. The code generator's dependencies could perhaps be reduced also, but we don't particularly care about that. If we publish the generated packages, then it shouldn't matter. But yes, publishing 300 packages is not something we can do without discussion with the broader community.

20:28 <discocaml> <sim642> There's 4379 packages right now, it'll be quite a percentage

20:29 <discocaml> <agarwal1975> The number of packages probably isn't a problem. I think the issue might be that whenever there is an update, all of them will get updated. Anyway, just managing that release process would be a ton of work, and we don't have the bandwidth for that right now.

20:31 <discocaml> <anmonteiro> I agree. I think it will only be a problem if there are many revdeps, which doesn't seem to be the case

20:31 <discocaml> <sim642> If they're all from the same repository, releasing shouldn't be that difficult. As long as dune-release/opam-publish are up for the package count

20:31 <discocaml> <anmonteiro> they're all pretty independent

20:34 <discocaml> <sim642> Revdeps is one thing, but 300 packages × dozens of opam CI configs is another

20:34 <discocaml> <sim642> Although compiler releases possibly spawn more jobs