[itchyjunk] has quit [Read error: Connection reset by peer]
hornhack has joined #ocaml
hackinghorn has quit [Ping timeout: 264 seconds]
zebrag has quit [Remote host closed the connection]
gravicappa has joined #ocaml
mbuf has joined #ocaml
hackinghorn has joined #ocaml
hornhack has quit [Ping timeout: 265 seconds]
spip has quit [Ping timeout: 264 seconds]
spip has joined #ocaml
vicfred has quit [Quit: Leaving]
Serpent7776 has joined #ocaml
mro has joined #ocaml
tjammer has joined #ocaml
olle has joined #ocaml
wonko has joined #ocaml
Haudegen has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mbuf has quit [Quit: Leaving]
hendursa1 has joined #ocaml
hendursaga has quit [Ping timeout: 276 seconds]
rond_ has joined #ocaml
gravicappa has quit [Ping timeout: 246 seconds]
gravicappa has joined #ocaml
bartholin has joined #ocaml
<d_bot>
<Deadrat> Also there is yojson and jsonaf
mro has quit [Remote host closed the connection]
mro has joined #ocaml
wonko has quit [Changing host]
wonko has joined #ocaml
rond_ has quit [Ping timeout: 256 seconds]
rond_ has joined #ocaml
tjammer has quit [Remote host closed the connection]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<ostera> in terms of efficacy of unification, what's the main difference between explicitly or implicitly introducing a new type variable in a function call? 🤔
<d_bot>
<ostera>
<d_bot>
<ostera> eg: `eqBy: ( 'a -> 'a -> bool ) -> 'a list -> 'a list -> bool`
<d_bot>
<ostera> vs: `eqBy: 'a. ( 'a -> 'a -> bool ) -> 'a list -> 'a list -> bool`
<d_bot>
<ostera> in practice I notice that when using functions from the Relude library (in Reason/ReScript), I am forced to annotate a lot of function arguments, and digging through their source I noticed they almost exclusively write upfront the type variables like in the second case
<d_bot>
<ostera> so i'm wondering how does this impact inference
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
glassofethanol has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
<d_bot>
<Drup> @ostera there is no difference.
[itchyjunk] has joined #ocaml
gravicappa has quit [Ping timeout: 246 seconds]
gravicappa has joined #ocaml
<d_bot>
<EduardoRFS> @ostera main difference is that it will fail is 'a is tried to be unified with a non env var
Haudegen has quit [Quit: Bin weg.]
<d_bot>
<ostera> @Drup huh, so its just a stylistic preference. Then the inference must be getting lost somewhere else 🤔
<d_bot>
<ostera> @EduardoRFS wdym by non env var?
<d_bot>
<EduardoRFS> @ostera main difference is that it will fail is 'a is tried to be unified with a non env var
<d_bot>
<NULL> `let eqBy cmp l1 l2 = let _ = cmp 0 0 in List.for_all2 cmp l1 l2` will only pass with your first type
<d_bot>
<Drup> In the implementation, yeah, it can be used to ensure polymorphism. In the *interface*, it's literally the same thing
<d_bot>
<ostera> " it can be used to ensure polymorphism" -- you mean the explicit `'a` or the implicit one?
<d_bot>
<octachron> In the interface, it *will* be the same thing in 4.14, the second form is not yet allowed in interface.
<d_bot>
<octachron> The explicit one.
<d_bot>
<ostera> hm, i'm not sure I follow what you mean by "ensure" here
<d_bot>
<octachron> In the first version, `'a` is an unification variable, that can be substituted to a more specialized explicit type.
<d_bot>
<octachron> `let id : 'a -> 'a x = 1 + x` is perfectly valid
Anarchos has joined #ocaml
<Anarchos>
I know ocamlgraph could be used to manipulate graph data structures, but what are the tools to do some visualisation of such graphs, interactive or not ?
<d_bot>
<ostera> @octachron but what good would `let id: 'a. 'a -> 'a = fun x -> 1 + x` do then? 🤔
<d_bot>
<octachron> This form is a type error.
<d_bot>
<octachron> There is no difference in term of *unification* but the constraint is different.
gravicappa has quit [Ping timeout: 246 seconds]
mro has joined #ocaml
waleee has joined #ocaml
<d_bot>
<octachron> You might be confused by the meaning of `'a . type_expr ` it is an explicit universal quantification over the type variable `'a` in `type_expr` and not an explicit introduction of a type variable.
<d_bot>
<ostera> thanks, the terminology is clearer to me now
<d_bot>
<ostera> what i'm still at odds with is why this library seems to need more type annotations when using it than others (base, containers, etc)
<d_bot>
<octachron> None of those annotations are needed.
<d_bot>
<octachron> Explicit universal quantification are only needed for polymorphically recursive function (a recursive function which is applied with various types in its own body), which is not used here (at a quick glance).
mbuf has joined #ocaml
<d_bot>
<ostera> okay so then it must be something else that's getting in the way of the inference
<d_bot>
<octachron> In which case do you need to add annotation?
<d_bot>
<ostera> things like `arr |> Relude.Array.map((item: t) => ...)`
<d_bot>
<ostera> I'll try to whip up a snippet that reproduces it, but if it isn't the universal quant. then it may just be something else in this codebase that's a little off
<smondet[m]>
(I'm experimenting with lwt-free concurrent programs, it's refreshing it's like I'm back in my 20's :) )
<smondet[m]>
Is the Event module of the stdlib still the recommended thing to use with the Thread one?
<smondet[m]>
Do y'all know whether it will be compatible with multicore/domains?
wagle has joined #ocaml
hornhack has joined #ocaml
wagle has quit [Client Quit]
wagle has joined #ocaml
hackinghorn has quit [Ping timeout: 265 seconds]
Haudegen has joined #ocaml
kakadu has quit [Ping timeout: 265 seconds]
waleee has quit [Ping timeout: 264 seconds]
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #ocaml
zebrag has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
kakadu_ has joined #ocaml
<sadiq>
good question
<sadiq>
it uses systhreads so my unofficial answer is "kinda"
<sadiq>
as in it will continue to work on multicore and will probably work between domains
<sadiq>
having a quick look through the code, I can't see any reason why not.
Everything has joined #ocaml
Anarchos has quit [Quit: Client closed]
mro has quit [Remote host closed the connection]
rond_ has quit [Quit: Client closed]
olle has quit [Ping timeout: 252 seconds]
rond_ has joined #ocaml
Anarchos has joined #ocaml
kakadu_ has quit [Ping timeout: 252 seconds]
<smondet[m]>
Thanks!
<smondet[m]>
Corollary: are there other modules/libraries that people would recommend to organize a Thread/Domains-based codebase in 2021?
olle has joined #ocaml
wonko has quit [Ping timeout: 265 seconds]
<d_bot>
<RegularSpatula> Does anyone know if brr JS bindings were done by hand, or generated with something like gen_js_api? (http://opam.ocaml.org/packages/brr/)
wonko has joined #ocaml
<Armael>
done by hand, I believe?
gravicappa has joined #ocaml
<d_bot>
<froyo> could this in any way be related to the whole pipefirst thing
<smondet[m]>
companion_cube: thanks! found them, i'll have a look
rond_ has joined #ocaml
<oriba>
is it "git+" if https url is used, or git:// if the git-entry is used?
waleee has joined #ocaml
<companion_cube>
That said once multicore lands I'll have to give more consideration to performance. Starting with the mutex wrapper probably.
Tuplanolla has joined #ocaml
<d_bot>
<rgrinberg> I have to say, I'm a bit nervous about everyone jumping on the bandwagon once multicore lands. If every program will try to saturate all the cores, we'll be back to square one with no performance gained.
<d_bot>
<rgrinberg> We need more efficiency rather than more parallelism
Serpent7776 has quit [Quit: leaving]
<companion_cube>
Well it'll be useful for cpu intensive programs, and irrelevant for the rest
mro has quit [Read error: Connection reset by peer]
mro has joined #ocaml
<d_bot>
<rgrinberg> *cpu intensive program running one at a time
<companion_cube>
Sure, as is their god given right :D
<companion_cube>
I mean, provide a -j param and all will be good
<companion_cube>
Just like it's already the case for multiprocessing programs
<d_bot>
<rgrinberg> for processes there's `nice`
<companion_cube>
For threads there's cgroups, i guess ?
<companion_cube>
Do you use nice for ocamlopt in dune though?
<d_bot>
<rgrinberg> Anyway, this is just a shout out to all the programs out there that stick to a single core and don't overheat my laptop to chase a little more throughput
<companion_cube>
I'm more worried about the ram
<companion_cube>
But even then multicore should beat multiprocess
<d_bot>
<rgrinberg> Nah. I want compilation to finish ASAP when I ask to dune compile something.
<d_bot>
<rgrinberg> though i stick to `-j` to keep things responsive
<companion_cube>
Well there you go :)
<companion_cube>
I don't have a lot of use cases for multicore proper, but the few i have would be nice
<companion_cube>
Also in the "finish as quickly as possible" category
<d_bot>
<rgrinberg> Yeah, I'm sure worried that we'll have primitives like `parallel_map` that will be abused to hell
<companion_cube>
Ah well
<companion_cube>
Maybe for a while, yeah, if scala is a history lesson
<smondet[m]>
(what I'm doing is not about parallelizing heavy computations, I'm more interested in trying to get rid of promise-monads && having HTTP servers that can scale better)
<companion_cube>
:D
<companion_cube>
The effect part is yet something else though
<d_bot>
<Deadrat> Plz gibe normal stacktraces
<d_bot>
<EduardoRFS> I don't think that most code is good enough to use parallel_map without having some weird bugs
<d_bot>
<EduardoRFS> maybe in the future as the ecosystem evolves and less global mutability is used, but right now a lot of things just don't work in parallel
<companion_cube>
Yes please for the stacktraces
<d_bot>
<Deadrat> Also shitposting
<d_bot>
<Deadrat> But
<d_bot>
<Deadrat> Plz gibe ecosystem that's migrated to effects in one day for good stacktraces
<d_bot>
<Deadrat> Anyway
<d_bot>
<Deadrat> It's quite interesting how the effect migration will go
<oriba>
Where is OCaml-Beam?
<d_bot>
<Deadrat> I really hope there will be no new lwt/async style splits in the ecosystem
<smondet[m]>
companion_cube: from an organization of the codebase perspective, it's not completely unrelated: direct-style & unpredictable preemptivity are things you get with Threads/Domains and effects
<smondet[m]>
(ok with just effects it's not completely unpredictable but extremely hard to figure out)
Stumpfenstiel has quit [Quit: No Ping reply in 180 seconds.]
Stumpfenstiel has joined #ocaml
hornhack has quit [Quit: Leaving]
Stumpfenstiel has quit [Ping timeout: 265 seconds]
<d_bot>
<Anurag> smondet: I think there is room to improve in HTTP server performance even in the current world of lwt/async :)
Haudegen has quit [Ping timeout: 260 seconds]
[itchyjunk] has joined #ocaml
cedric has quit [Quit: Konversation terminated!]
<companion_cube>
I thought httpaf was fast?
<smondet[m]>
From pure http-overhead yes, but *some* parallelism answering requests must help also a lot with latency of many applications, e.g. many HTTP patterns are "parse big blob → compute + do I/O → serialize big blog", often parsing/serialization are bad at being cooperative while being easy to parallelize.
<smondet[m]>
Anurag: Yes I know, and I'll be likely still be maintaining Lwt codebases in 2030 :)
<smondet[m]>
But multicore / direct-style / effects are coming (back), it's worth (and fun!) experimenting with them now.
<d_bot>
<Anurag> samondet: of course. I don't mean to say no to experimenting with effects. I'm also looking forward to learning more about them :)