jabuxas has quit [Remote host closed the connection]
jabuxas has joined #ocaml
myrkraverk_ is now known as myrkraverk
waleee has quit [Ping timeout: 260 seconds]
jabuxas has quit [Ping timeout: 268 seconds]
hsw has quit [Quit: Leaving]
<discocaml>
<struktured> That was quite literally a drop in replacement as it's a fork of nocrypto anyhow. Good choice.
<discocaml>
<darrenldl> is there any TUI app testing frameworks around in the style of cram tests? Something like https://github.com/charmbracelet/vhs which can already do screenshot, but I also want the ability to compare the screenshot/terminal against previous version
deadmarshal_ has quit [Remote host closed the connection]
mbuf has joined #ocaml
Serpent7776 has joined #ocaml
deadmarshal_ has joined #ocaml
<discocaml>
<dinosaure> My actual plan is to upstream httpaf's PRs and fork it in a new name to avoid module name clash
<discocaml>
<dinosaure> And avoid any pin by this way 🙂
<discocaml>
<lowlowcode_96272> Im using ocaml-fswatch https://github.com/kandu/ocaml-fswatch but the example code doesnt trigger an event when creating or updating file... Any suggestions ?
<discocaml>
<dinosaure> Sorry, but I'd like to follow what the authors/maintainers have done and as agreed with them 😕
<discocaml>
<anmonteiro> no need to apologize at all. just unfortunate that there will still be 2
<discocaml>
<anmonteiro> uh.. now 3
<discocaml>
<lowlowcode_96272> Can someone has used the fswatch lib ? Does it works for you ?
gooby323 has quit [Ping timeout: 264 seconds]
<discocaml>
<limp.biskit> i was not under the impression httpaf was still maintained. nobody’s merged anything in years
<discocaml>
<lowlowcode_96272> Any idea how to build a simple file watcher for multiplatform ?
<discocaml>
<dinosaure> they use an internal version and they did not upstream their changes but it's actually used 🙂
<discocaml>
<limp.biskit> oh right, that makes a lot more sense
<discocaml>
<anmonteiro> Also a bit unfortunate you’ll have to fork h2, too
<discocaml>
<dinosaure> I did not plan to fork h2 🙂
<discocaml>
<anmonteiro> Do you plan on depending on 2 http1 libs?
<discocaml>
<dinosaure> I mean, another question is probably: why h2 should depends on something related to http/1.1 😕
<discocaml>
<anmonteiro> So that you can share status method, etc types
<discocaml>
<anmonteiro> I wouldn’t be opposed to extracting those to a common library
<discocaml>
<dinosaure> I prefer the second solution IHMO if you can
<discocaml>
<anmonteiro> I’m saying right now h2 depends on httpaf. Next release will depend on my fork
<discocaml>
<anmonteiro> Unless we release this common lib first
<discocaml>
<dinosaure> for my point of view, I prefer to have a standalone types (method, headers, etc.) for h2, I mean it's two different protocols and the way to manipulate for instance headers is not the same with http/1.1 (for instance)
<discocaml>
<dinosaure> it's fine to have a "semi"-duplicate here and merge then these types on a higher library (like `piaf` in your case)
<discocaml>
<anmonteiro> I understand your point and that would be nice.
<discocaml>
<anmonteiro>
<discocaml>
<anmonteiro> I’m also describing reality
<discocaml>
<dinosaure> should I make an issue?
<discocaml>
<anmonteiro> Probably not necessary. Would you like me to create this common library?
<discocaml>
<dinosaure> yes, it will be really nice 🙂
<discocaml>
<anmonteiro> Absolutely. On my list
gooby323 has joined #ocaml
gooby323 has quit [Remote host closed the connection]
mbuf has quit [Quit: Leaving]
<discocaml>
<grianneau> Hi, are there any users of Imandra out there?
malte has quit [Ping timeout: 252 seconds]
malte_ has joined #ocaml
malte_ is now known as malte
toastal has quit [Ping timeout: 268 seconds]
toastal has joined #ocaml
sroso has quit [Quit: Leaving :)]
<discocaml>
<limp.biskit> i actually would love this
<discocaml>
<limp.biskit> been working on a framework and i find myself having to write a whole bunch of stupid conversion functions to not hard depend on httpaf (or httpun or httpaf2 :p)
<discocaml>
<limp.biskit> would get one step closer to any sort of interoperability
<discocaml>
<limp.biskit> all for this but would this new upstream be actively and consistently maintained? an upstream that everyone can use for three months until it gets forked again is not a shining prospect
<discocaml>
<dinosaure> yes, we actually have few usage for unikernels and some of our tools, it's a long run but we would like to consolidate `http-lwt-client` and continue our work on `httpcats` and keep the compatibility with unikernels
<discocaml>
<dinosaure> so we would like to use it at first & improve it then (as we usual do for any libraries made/maintained by robur)
<discocaml>
<limp.biskit> i thought someone else maintained httpaf
bartholin has quit [Quit: Leaving]
<discocaml>
<dinosaure> I checked issues and PRs and, regardless the Upgrade PR, I did not find big issues (something which requires a lot of work). So, for my point of view, `httpaf` is more or less sufficient for what it wants to provide. To clarify, `httpaf` is not sufficient for basic use, but it is sufficient for what it is trying to offer. In this sense, only the Upgrade PR needs to be merged. I've asked the maintainers/authors this question several times and
<discocaml>
<dinosaure> In this sense, I've asked for "permission" to fork since, from our point of view (and theirs), the project works, it has no fundamental problems and just needs some maintenance work (which, as it happens, Robur has known about for several years now 🙂 ).
<discocaml>
<limp.biskit> yes, but what then differentiates this fork from the one people are already using?
<discocaml>
<limp.biskit> i misunderstood you, i thought this was upstreaming changes to the original httpaf repo, not another fork
<discocaml>
<leostera> whatever happened to the http library with common types? 🤔
<discocaml>
<limp.biskit> the one used by cohttp?
<discocaml>
<dinosaure> From our point of view, the problem is (for the last 7 years or so) that the existing forks are not co-usable because they use the same module name and it is the purpose of our fork to change only the name (here again, the authors of http/af are aware of this).
<discocaml>
<dinosaure>
<discocaml>
<dinosaure> Another difference is that we're following in the footsteps of what the authors have already done (and which seems to work for them), whereas the other forks diverged much earlier (notably earlier than the work on Upgrade, which was initiated on http/af).
<discocaml>
<limp.biskit> anmonterio just changed his module names though
<discocaml>
<dinosaure> yes, but he did not follow what initial authors did 🙂
<discocaml>
<limp.biskit> i don’t know, it’s your choice but i either like or do not notice the changes in (what is now) httpun. to me a second fork it just seems like duplicating work
<discocaml>
<limp.biskit> at the very least i think there should be a small, common and interoperable package for types before any of this is finalised
<discocaml>
<dinosaure> I don't know why httpun is appearing today when the problem with names has been known for 7 years now. From my point of view, a fork is clearly a choice with many implications for the community and the people involved. In this sense, as far as we're concerned, we've made several efforts with the initial authors to be totally transparent about our objectives and the problems encountered. And that's why we want to continue in their direction w
<discocaml>
<limp.biskit> your social framework produces excellent software, i am just worried about interoperability and the urge to rewrite the world
<discocaml>
<limp.biskit> i don’t see either option as a bad outcome, but greater collaboration is rarely a bad thing at least as far as reducing fragmentation
<discocaml>
<leostera> yup – would be excellent to just make this package the slimmest default since its also very easy to find
<discocaml>
<leostera> social framewor = robur.coop ?
<discocaml>
<leostera> social framework = robur.coop ?
<discocaml>
<limp.biskit> that package seems to include the core cohttp parser
<discocaml>
<limp.biskit> in addition to types
<discocaml>
<limp.biskit> makes it unsuitable to me
<discocaml>
<leostera> i'd strip it down to just the barebone types tbh
<discocaml>
<leostera> (i don't use the cohttp parsers either)
<discocaml>
<limp.biskit> i haven’t used cohttp in a bit, how much difference is there between httpaf’s types and it
<discocaml>
<leostera> i'm talking more from the discoverability angle than the actual package contents btw, i don't care much for its actual contents, but you'd hope that from the name it'd be the most basic http types that everyone can use
<discocaml>
<hannes6838> and from my experience - please let's have a common http library that doesn't come with "parser" or "sexplib" or "ppx" as dependencies -- since that will turn away people. just have a basic set of (useful, agreed-on) types (and if there's need for compare functions, or a common Header module, that can be proposed)
<discocaml>
<leostera> +1
<discocaml>
<leostera> also just using `string` and `bytes`
<discocaml>
<hannes6838> but this unhealthy "fork and vendor and fork again, and let's vendor" won't lead us anywhere -- if you feel like missing out, take a look at the mirage-www repository and go through the path of "try to update to dream-1.0alpha6" -- yes, you'll encounter a myriad of git repositories and ask yourself what dream is actually using and why
<discocaml>
<hannes6838> @leostera that's the spirit. string for immutable stuff! 🙂
<discocaml>
<limp.biskit> i think a header module is worth implementing
<discocaml>
<limp.biskit> anything beyond that belongs in a seperate library (wink wink)
<discocaml>
<limp.biskit> better than piaf_httpaf_fork2
<discocaml>
<hannes6838> [and yes, indeed, as a side note, we have no git.robur.coop etc. up at the moment, all SSDs in the server broke at the same time (on the night from sunday to monday), we're in the process to get back our services (email is working \o/, DNS as well) -- and also investigate data recovery (SSDs are not at a recovery company] -- it is a stressful thing, but also a price you pay for self-hosting. at the moment, we're waiting for the diagnosis of
<discocaml>
<limp.biskit> apart from unreleased stuff like caqti-miou, is there any difference between packages on there and github
<discocaml>
<limp.biskit> e.g. miou
<discocaml>
<limp.biskit> for now i have just been pinning miou to gh to build httpcats
<discocaml>
<limp.biskit> also im sorry about the ssds, god that sounds like a nightmare
<discocaml>
<dinosaure> I just merged a PR about `Miou.call_cc`/`Miou.async` (see https://github.com/robur-coop/miou/pull/23) - we just reach the deadline. And I will make a release of `miou.0.2.0` as soon as I can (probably today)
<discocaml>
<dinosaure> then, I will try to prepare all other pull-requests (like miou-caqti, mirage-crypto, miou-tls), it's a long run but we reach the end soon 🙂
<discocaml>
<drupyog> For people out of the loop, what are the reason for the proliferation of http libraries ? cohttp and httpaf (and the stuff that was before cohttp) I used to understand, but I didn't follow up afterwards
<discocaml>
<drupyog> (It's ... interesting how what is basically a parser can be redone differently so many times)
<discocaml>
<drupyog> (that remark is not OCaml specific at all :p)
<discocaml>
<drupyog> (that last remark is not OCaml specific at all :p)
<companion_cube>
it's a parser intermixed with a network protocol, ofc there's going to be many ways of doing it :)
jabuxas has quit [Quit: oops :p]
jabuxas has joined #ocaml
jabuxas has quit [Client Quit]
jabuxas has joined #ocaml
<discocaml>
<bluddy5> Dang the single maintainer model github encourages is so problematic. People move on in life.
<discocaml>
<bluddy5> Maybe it's more that opam encourages it together with github.
<companion_cube>
it doesn't encourage it, it's trivial to make organizations
<discocaml>
<bluddy5> I wouldn't say trivial. It's an easy default to just create a personal repo.
<discocaml>
<bluddy5> Especially once you consider you'd want an org per project you're working on.
<companion_cube>
it's a few clicks no?
<discocaml>
<drupyog> @dinosaure oh wow, picos is *big*. I expected a more limited number of primitives from the pitch
<companion_cube>
why? if you have that many projects that it's a problem… well done I guess
<discocaml>
<bluddy5> Every repo should have the option of becoming an org.
<companion_cube>
core picos isn't big, @drup
<companion_cube>
it's trigger+fiber+computations+a handful of effects iirc
<discocaml>
<bluddy5> Say you have 3 projects. You want to make sure someone can maintain them in case they take off. 3 different orgs is a pain.
<companion_cube>
the repo is bigger
<companion_cube>
3 personal projects taking off, and you can't make orgs when that happens?
<companion_cube>
who are you, bunzli? :P
<discocaml>
<bluddy5> They can also somewhat take off. Some people use them. If they were orgs, it would be so easy to let people take over your projects.
<companion_cube>
🤷
<companion_cube>
I mean you can make people contributors on your projects
<companion_cube>
that's what happened with `qcheck` for example, I'm totally hands off now
<discocaml>
<drupyog> ccube: I imagine so, yes, the doc doesn't make it so clear what the core is tho
<discocaml>
<darrenldl> would be keen to hear from its users too
<discocaml>
<drupyog> @dinosaure miou doesn't depend on picos formally ?
YuGiOhJCJ has joined #ocaml
<discocaml>
<drupyog> (and what's your issue with the current Fiber API ?)
<discocaml>
<dinosaure> I've informed Vesa that I'd like the core to be available in OCaml :3 - but, given the basic constraint we have with unikernels (and static linking), I prefer to be dependency-free. About Fiber, I'm not a big fan of the internal table (too many `Obj.magic` for my taste) and I actually don't use it at all.
<discocaml>
<dinosaure> (I mean, `Fiber` is actually just a `Computation.t` plus the internal table)
<discocaml>
<drupyog> yes, fiber seems a bit weird, given Computation (aka Promise) exists
<discocaml>
<drupyog> yes, fiber seems a bit superfluous, given Computation (aka Promise) exists
<discocaml>
<drupyog> right, but upstreaming picos core seems a bit early. In the meantime, we should tend towards having everyone on the same page
dstein64- has joined #ocaml
dstein64 has quit [Ping timeout: 260 seconds]
dstein64- is now known as dstein64
<discocaml>
<dinosaure> Yes, that's the crux of the problem: adoption on the one hand and integration into OCaml on the other 🙂 . As far as I'm concerned, I've already adopted Miou (via a copy) and we can consider this a real example and then push for integration into OCaml (even though I don't depend on picos via opam). Then, I think that such an approach also frames what is at the heart of picos and can, potentially, have a better chance of being integrated as
<discocaml>
<dinosaure> Then, we can imagine an `miou-with-picos` which repeats exactly everything but depends on `picos` & let people to play with `Trigger.Await` across schedulers
<discocaml>
<drupyog> copying picos kinda defeat the purpose :p
<discocaml>
<drupyog> vendoring picos kinda defeat the purpose :p
<discocaml>
<drupyog> but I understand
<companion_cube>
@dinosaure FLS is super important though
<companion_cube>
we all need to agree on core types :3
<discocaml>
<dinosaure> hmhmm depending on my ambition 😄 if it's like: I don't want to build bridges, yeah it's a defeat but I don't want to go to this path I prefer to talk and be involve 🙂
<discocaml>
<limp.biskit> thought ocaml was statically linked by default?
<companion_cube>
nope
<discocaml>
<limp.biskit> for ocaml code at least
<companion_cube>
I think it's fine to vendor picos for now, to see how well it integrates, but later depend on it when it reaches 1.0
<companion_cube>
oh yeah that, sure
<companion_cube>
but you don't get an actual static binary
<discocaml>
<dinosaure> and I agree with you companion_cube, my last blocker is the Current effect but you already know that I think
<companion_cube>
I don't remember :D
<discocaml>
<drupyog> ccube: I wonder how much the rest (the permit/forbid stuff) is essential, but I can see how rebuilding it on top would be a pain if someone needs it
<discocaml>
<limp.biskit> does picos have any C deps?
<companion_cube>
is it bad to have a Current effect?
<companion_cube>
no, picos shouldn't have C deps
cross has quit [Remote host closed the connection]
<discocaml>
<drupyog> @dinosaure the presence of `Current` surprised me, I must say
<discocaml>
<dinosaure> it's required for mutex and condition to see avoid that a fiber double-lock a mutex for instance: you must identify who wants to lock/unlock
<discocaml>
<drupyog> I see
<companion_cube>
it's also a way to get FLS no ?
<discocaml>
<dinosaure> yes, but I don't use this part 🙂
<companion_cube>
and if you want to implement structured concurrency it can be a way to attach sub-fibers to the current one
<companion_cube>
yeah but I do :p
<companion_cube>
and other people will, I'm sure
<discocaml>
<dinosaure> I think on this specific question, we should just split (Current & Get_FLS) and the first one should just return an unique identifier
<discocaml>
<dinosaure> because it's actually the usage for mutex & condition
<companion_cube>
ah, I guess yeah
<companion_cube>
idk, I use thread-local-storage for this kind of stuff
<companion_cube>
(even though it's based on a hack, whatever)
<discocaml>
<drupyog> one thing I don't see is a way to have efficient callbacks which receive the value of a computation. For some reason, Trigger doesn't receive the value
<companion_cube>
ah yeah
<companion_cube>
it's a big thing, Vesa really doesn't like the idea of callbacks
<discocaml>
<dinosaure> @polytypic ^ sorry to disturb you but our discussion is probably interesting for you 🙂
<companion_cube>
I mean he's not wrong, the issue is: where does the callback run
<companion_cube>
so instead you need to await the trigger and then peek/get the underlying value from the computation
<companion_cube>
(trigger being optimized for avoiding allocs iirc)
<companion_cube>
create a trigger and await it* sorry
<discocaml>
<lowlowcode_96272> I want to use the character % with Printf.sprintf , how can I escape it ?
<discocaml>
<drupyog> Okay, so there is one limited form of callback that is quite essential for efficiency in some context, `chain computation1 computation2` which callbacks on computation2 for the value v, and use it to fullfill computation1
<discocaml>
<dinosaure> Yes, with another `%` like `printf "%%"`
<discocaml>
<drupyog> and in that case, the place where it runs doesn't matter
<discocaml>
<lowlowcode_96272> I get "Unknown field include_subdirs"
<discocaml>
<lowlowcode_96272> Oh its works now that I put it at first line
pi3ce has quit [Quit: No Ping reply in 180 seconds.]
pi3ce has joined #ocaml
<discocaml>
<anmonteiro> The issue I linked explained the plans. This is not coming all of a sudden; I actually detailed the plans in that comment because people have been asking me to publish the lib
gooby323 has quit [Ping timeout: 268 seconds]
<discocaml>
<anmonteiro> Dream is the biggest motivation since they’re using my libraries; and won’t have to depend on vendoring them anymore