00:16 <discocaml> <cemerick> Same critique applies, they're both just diffing textual output

00:44 <discocaml> <regularspatula> Huh, I tend to use them a lot

04:35 <discocaml> <cemerick> yeah, they're pretty popular in OCaml; moreso, I think, than in almost any other language?

04:35 <discocaml> <cemerick> @regularspatula yeah, they're pretty popular in OCaml; moreso, I think, than in almost any other language?

04:38 <discocaml> <cemerick> speaking of eio-ish things, https://git.robur.coop/robur/miou seems interesting

04:40 <discocaml> <cemerick> anyone work with it much yet? Seems it's not been mentioned @ discuss outside of companion_cube listing it off as a "contender" vis a vis moonpool, eio, etc

04:47 <discocaml> <cemerick> "miou…is more in-line with…our opinions about community driven library" wooof https://mastodon.social/@dinosaure/110886964304168763

04:50 <discocaml> <cemerick> very zesty @dinosaure 😜, how would you characterize miou's status?

09:42 <discocaml> <dinosaure> Yeah, it's basically a round robin scheduler 🙂

09:43 <discocaml> <dinosaure> Currently we are focus onthe documentation but the core is ready

09:43 <discocaml> <dinosaure> I will probably do an anouncement next month

10:09 <discocaml> <dinosaure> But yeah the library is ready, we did several tries to see if the API is correct, ar least if ideas that propose `miou` are correct

10:36 <discocaml> <dinosaure> About this point, I will precise a bit more what happened in my blog I think. But yeah, we would like to not depend on `eio` for "social reasons". So it's not originally a technical reason to make a new scheduler even if, currently, we have some deep technical differences.

10:38 <hannes> it is fair to say that the design is different, as is resource management. and at the bottom the lines of code is drastically different (though obviously the featureset is different).

10:55 <discocaml> <dinosaure> Actually, if you are interested, https://github.com/roburio/miou/blob/main/lib/state.mli explains the deep difference about our usage of effects and and the usage of others schedulers. The key is the availability for any tasks to have an equal opportunity to be in-sync with system events.

10:57 <discocaml> <dinosaure> (which is the main advantage of a round robin scheduler, of course, some disadvantages exist but we will try to precise that on the documentation)

10:58 <discocaml> <darrenldl> i made a tui chat app demo with eio some time ago, might be time to try porting that to miou just to see how using miou feels

11:07 <discocaml> <dinosaure> (And I just realize that I did some jokes on the doc that we probably should avoid 🙃)

12:20 <hannes> darrenidl; I think that's a excellent idea

12:44 <companion_cube> @cemerick I wouldn't say moonpool is a competitor to Eio or Miou btw. It's more of an alternative to domainslib. Like a classic thread pool, not a layer above epoll which would be used for IO

12:59 <discocaml> <dinosaure> (And I just realize that I did some jokes on the doc that we probably should avoid 🙃)

13:01 <discocaml> <dinosaure> Yes, I agree with that 🙂 for pure algorithm (like SAT solver :p), `moonpool` is probably better

13:02 <companion_cube> SAT solvers are hard to parallelize but otherwise yeah

13:04 <discocaml> <dinosaure> You are better than me about that 🙂

15:25 <discocaml> <darrenldl> hannes: oops irc can see deleted messages : v

15:25 <discocaml> <darrenldl>

15:25 <discocaml> <darrenldl> i was thinking its a silly to bring up, but good to know someone thinks its not a terrible idea : D

15:28 <hannes> darrenldl: it'd be interesting to hear from your experience.. any outside feedback / comparison is always very useful (to eventually re-evaluate the API)

15:31 <discocaml> <darrenldl> fs has been a pain point to me in eio, so id be curious how it stacks up in miou (or if its within miou's purview)

15:33 <discocaml> <darrenldl> eio feels overreaching at points, im guessing miou would make me think less so

15:41 <hannes> "fs"?

15:47 <discocaml> <darrenldl> file system

15:47 <discocaml> <darrenldl> paths have to be computed using eio primitives

15:48 <discocaml> <darrenldl> which i have mixed feelings about

15:50 <discocaml> <darrenldl> namely you have to specify the "root" of path resolution, which can either be root of file system, or current working directory

15:50 <discocaml> <darrenldl>

15:50 <discocaml> <darrenldl> supposedly the latter can provide a safety net in avoiding looking up to the wrong place

15:50 <hannes> hmm

16:02 <hannes> I can see pain there. I appreciate something along these lines to be optional - i.e. define the basic functions (open/read/write/close) on "string", and document that users can use "fpath" or something along these lines if they want more safety

16:04 <hannes> since "sandboxing" / escaping from a folder involves likely more than the fs API (haven't looked into eio, but e.g. links come to mind, as do relative paths)

16:06 <haesbaert> I think the "nice thing" is to provide some openat relative thing if you want to be safe and so on

16:07 <discocaml> <darrenldl> the very annoying consequence is i need to pass down either the fs component of eio's environment, or pass the entire environment down

16:07 <haesbaert> I've felt your pain

16:07 <discocaml> <darrenldl> i really feel like the environment thing should operate at dune virtual library level, not at a vale level

16:07 <discocaml> <darrenldl> value level*

16:09 <hannes> haesbaert: openat is nice indeed, but you can just expose that in your API :)

16:09 <haesbaert> ack, that's what I meant

16:10 <hannes> darrenldl: I honestly still don't understand what this "environment" is, and why I should care... but then I may have read too many POSIX manpages (and dislike having to pass "environments" and other global state through) ;)

16:10 <haesbaert> hannes: it's the "object capability" thing, you get the "fs from an env"

16:11 <hannes> haesbaert: thanks. can i take a beer instead?

16:11 <haesbaert> a beer is easy, I'd take a punch and would still think it was worth it

16:12 <haesbaert> speaking of beer....

16:14 <discocaml> <darrenldl> hannes: the entry point to eio passes you an emvironment (collection of capabilities as mentioned): <https://ocaml.org/p/eio_main/latest/doc/Eio_main/index.html#val-run>

16:14 <discocaml> <darrenldl> you grab things like stdin, stdout, clock, monotonic clock, file system out of this environment

16:14 <haesbaert> at any rate, if you're building stuff like an httpd, you should chroot and drop to nobody anyway

16:16 <discocaml> <darrenldl> if one really wants sandboxing, bwrap is around the corner

16:16 <haesbaert> but that's highly unportable

16:17 <haesbaert> but then again, who cares about portability in 2023, the world is linux and everyone else eats cake

16:18 <discocaml> <darrenldl> i think it should still be something that appeals to os level stuff than at a language api level in a language with no capability system...but im barking up the wrong tree judging last discussion on ocaml.org

16:19 <haesbaert> you're not, virtually no one likes the capability stuff

16:20 <haesbaert> it's a recurrent topic of content, to put it mildly

16:20 <haesbaert> *contention

16:20 <discocaml> <darrenldl> sadly so

16:22 <haesbaert> you can use the Eio.LowLevel directly nowadays I think, at least that was the plan

16:22 <discocaml> <darrenldl> oh i didnt know about that, huh

16:23 <haesbaert> it's kinda new, worth the shot :)

16:24 <discocaml> <darrenldl> ah okay, new stuff, neat

16:40 <discocaml> <darrenldl> i might look into contributing to miou after studies

16:40 <discocaml> <darrenldl>

16:40 <discocaml> <darrenldl> eio code was a bit complex everywhere i looked, presumably to squeeze performance, but still

17:14 <discocaml> <lecondorduplateau> f*ck apolitical libraries, that's part of the artistic direction ☭

17:40 <discocaml> <dinosaure> From my experience, the performance is probably the last thing you should think about and the first must be the API. If you improve something on performances but you did not agreed on a specification on what the stuff do upfront, IMHO, you just make a new code, you did not improve it. When we talk about performances, an oracle matters and the specification matters to be able to evaluate and compare what you did.

17:42 <discocaml> <dinosaure> About `miou` and fs, it's very like `lwt` and `lwt.unix`. `miou` has the basics and `miou.unix` (currently named `miouu` but the name, even if it's fancy, is not usable) has all POSIX stuffs.

17:47 <discocaml> <dinosaure> This separation is related to unikernels of course but I don't think that we experiment something new on this side 🙂 . I mean, for +10 years `lwt` keeps such choice and it was fine.

20:04 <Anarchos> rgrinberg i have questions about dune, spawn github repositories.

20:14 <discocaml> <Et7f3 (@me on reply)> Ask them

20:19 <Anarchos> i see that in the dune/vendor folder, spawn is retrieved from github.com/rgrinberg/spawn, which is behind janestreet's version. So if i have a pull request in spawn to do, where to direct it ? Janestreet or rgrinberg ?

20:19 <rgrinberg> janestreet

20:20 <Anarchos> ok

20:20 <Anarchos> so i have to clone the janestreet spawn repo instead of yours.