<discocaml>
<darrenldl> so no longer tied to mingw and cygwin?
<discocaml>
<darrenldl> wait im asking stupid question i feel. is mingw native?
<discocaml>
<yawaramin> it was never tied to MinGW or Cygwin. OCaml itself has always supported Windows natively. MinGW/et al. were always needed to support the surrounding tools, like opam
<discocaml>
<yawaramin> and packages which use Unix-isms
<discocaml>
<yawaramin> like eg if a package uses bash/sed/awk as part of its installation
<discocaml>
<darrenldl> ahhh
<companion_cube>
half of the `Unix` module is unsupported on windows though
<companion_cube>
the most important things work, I think, but it's fairly biased towards, well, unix
<discocaml>
<yawaramin> yeah those functions are marked as unsupported, but more importantly, OCaml compiles and runs on Windows natively
<discocaml>
<yawaramin> it might be more accurate to call that module `Posix` though
<companion_cube>
yeah probably
gzar has quit [Quit: WeeChat 4.2.2]
wingsorc has quit [Ping timeout: 240 seconds]
jbowen has joined #ocaml
jabuxas has quit [Quit: oops :p]
<dh`>
nah, "posix" means something specific and "unix" is much more general
<companion_cube>
I _think_ that `Unix` exposes a subset of posix
<companion_cube>
can't think of anything in it that's not in posix
<dh`>
posix has a lot of random lacunae
<dh`>
less since they embraced the entire SVID uncritically, but there are still quite a few things missing
<dh`>
other things are wrong because they came from the SVID :-)
<companion_cube>
the whole signals thing is terrible
<companion_cube>
but well, it's posix, can't avoid it
<dh`>
signals are terrible in general
<dh`>
someone famously described signals as a "semantic cesspool" ages ago (can't remember who, alas) and it's pretty accurate
mbuf has joined #ocaml
germ has quit [Ping timeout: 268 seconds]
germ has joined #ocaml
Serpent7776 has joined #ocaml
Serpent7776 has quit [Ping timeout: 268 seconds]
bartholin has joined #ocaml
Serpent7776 has joined #ocaml
olle has joined #ocaml
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #ocaml
Serpent7776 has quit [Ping timeout: 260 seconds]
neiluj has joined #ocaml
<neiluj>
Hi! I'd like to execute sequentially f () -> a then g () -> () but f is blocking and returns when g terminates. it looks like let* a = f () in let* () = g (). I rewrote it to Lwt.dont_wait (fun () -> f()) (fun _ -> ()); let* () = g () but I'd like to use the returned promise by f. How would you do that?
<discocaml>
<darrenldl> is `f : unit -> a Lwt.t`?
<neiluj>
yes
<discocaml>
<darrenldl> then i think you can just do let promise = f () in let* () = g () in let* resolved = p in do_whatever resolved
<discocaml>
<darrenldl> ah, sorry, the last p should be promise
<discocaml>
<darrenldl> let* resolved = promise in ...
<neiluj>
oh, very elegant!thx
<neiluj>
so when you call f() Lwt executes it?
<neiluj>
it just doesn't wait for termination
<discocaml>
<darrenldl> let* "forces" the promises and blocks, so just plain `let` lets you just hang onto it
<discocaml>
<darrenldl> since f() blocks at some point to wait for g (), Lwt will get to schedule it when that happens
<discocaml>
<darrenldl> so in the above code fragment, `let promise = f () in` will run body of `f` up to any yield (can be from IO, can be from blocking on any lock etc)
<discocaml>
<darrenldl> then we proceed to `let* () = g () in` where this waits for `g ()` to run till a resolution (of value `()`)
<discocaml>
<darrenldl> at that point, `f ()` should continue forward since g has finished, and continue toward resolving `promise`
<discocaml>
<darrenldl> `let* resolved = promise in` waits for resolution of said `promise`
<discocaml>
<darrenldl> (an alternative reading is to rewrite `let*` back into `Lwt.bind`, which makes where blocking happens more obvious)
<neiluj>
hmm, it doesn't work i believe because f () merely calls an executable, and g() waits for an event from an other executable that communicates with the first, so Lwt's runtime isn't aware of the business logic of f and g
<neiluj>
just tried and yes f is still blocking
<discocaml>
<darrenldl> does f only depend on g or does it also depend on the executable to finish fully?
<neiluj>
but that's a good method to keep in mind, will likely use it in the future
<neiluj>
f depends on the executable to finish fully yes
<discocaml>
<darrenldl> are you making use of pipes?
<discocaml>
<darrenldl> if you are piping in and out from the executable, you'll have to close the pipe for the executable to exit (from my flawed recollection from experience)
<neiluj>
no pipes, though named pipes are used to read the executable events
<neiluj>
oh, so yes there are pipes
<discocaml>
<darrenldl> are those closed?
<discocaml>
<darrenldl> cause i recall being very confused when strace doesn't exit after i have read everything from the named pipe, only to find out i had to close everything
<neiluj>
the pipes are closed yes
<discocaml>
<darrenldl> gonna ask the classic question: is the code public?
<neiluj>
i noticed some strange behaviour with having to close named pipes to be able to read (flushing didn't work) on mac
<neiluj>
it is but it's a beast, and it's my work to sort this out so I don't want to abuse of your help
<discocaml>
<darrenldl> gotcha, fair enough
<discocaml>
<darrenldl>
<discocaml>
<darrenldl> then i uh suggest confirming where f blocks precisely, e.g. does it go through if you don't wait for executable to finish
cedric has joined #ocaml
cedric has quit [Client Quit]
wingsorc has joined #ocaml
<neiluj>
thanks for the suggestion!
<neiluj>
darrenldl, managed to fix the issue, your advice actually worked but the order of the function calls and the resolution of promises was off
<neiluj>
:)
ocra8 has joined #ocaml
wingsorc has quit [Remote host closed the connection]
wingsorc has joined #ocaml
jabuxas has joined #ocaml
<discocaml>
<darrenldl> neiluj: oh oops. what's the actual order?
ocra8 has quit [Ping timeout: 256 seconds]
<neiluj>
i did (within Lwt monad): let* p = f() in and* p' = h() in g() to execute f and g concurrently but still enforce the ordering start f first then g using h
<discocaml>
<darrenldl> huh
<neiluj>
yes?
<discocaml>
<darrenldl> no just i thought let* resolves the promise, think i misunderstood then
<neiluj>
it does
<neiluj>
just used and* to join the two promises
<neiluj>
and run them concurrently
<discocaml>
<darrenldl> how does that allow g to run concurrently though?
<discocaml>
<darrenldl> (f and h, sure, but f and g?)
gzar has joined #ocaml
<companion_cube>
it starts both promises first, then binds their results
<neiluj>
oh sorry meant `let* p = f() in and* p' = (let* _ = h() in g()) in ..
<discocaml>
<darrenldl> ohh
<discocaml>
<darrenldl> what does h do?
cr1901_ is now known as cr1901
jabuxas has quit [Ping timeout: 255 seconds]
ocra8 has joined #ocaml
olle has quit [Ping timeout: 240 seconds]
jabuxas has joined #ocaml
neiluj has quit [Ping timeout: 252 seconds]
chiselfuse has quit [Remote host closed the connection]
farn_ has quit [Ping timeout: 255 seconds]
farn_ has joined #ocaml
chiselfuse has joined #ocaml
Serpent7776 has joined #ocaml
chiselfuse has quit [Remote host closed the connection]
housemate_ has joined #ocaml
chiselfuse has joined #ocaml
mbuf has quit [Quit: Leaving]
ocra8 has quit [Quit: WeeChat 4.2.2]
neiluj has joined #ocaml
Tuplanolla has joined #ocaml
ocra8 has joined #ocaml
sadome has joined #ocaml
sadome has joined #ocaml
sadome has quit [Excess Flood]
jabuxas has quit [Ping timeout: 256 seconds]
neiluj has quit [Ping timeout: 260 seconds]
nickiminjaj has joined #ocaml
Guest57 has joined #ocaml
<Guest57>
Hey, in what kind of task OCaml may be more useful than other languages?
<discocaml>
<Kali> compilers
bartholin has quit [Quit: Leaving]
<Guest57>
Why?
<Guest57>
And is it the only field?
<Guest57>
Maybe... what's the advantage over Haskell?
jabuxas has joined #ocaml
<discocaml>
<contextfreebeer> Better tooling, alex/happy kind of sucks
<discocaml>
<contextfreebeer> > <Guest57> And is it the only field?
<discocaml>
<contextfreebeer> also proof assistants and theorem provers
<discocaml>
<Kali> advantage over haskell: - better tooling by far - optional laziness - non-semantic whitespace - much faster build times - fully inferrable type system minus GADTs (haskell has many extensions that make it require type annotations in some cases) - very powerful module system - prefers alphanumeric functions over symbols in almost every case
<Guest57>
What about multithreading? I heard that Haskell is way better in terms of multithreading
<discocaml>
<limp.biskit> Guest57 ocaml multithreading is new but it’s pretty good
<discocaml>
<leviroth> Multi threading is _not_ new
<discocaml>
<limp.biskit> eio and miou are direct-style concurrency schedulers and moonpool is good for processing work
<discocaml>
<limp.biskit> i mean domains
<discocaml>
<leviroth> Multiprocessing new
<discocaml>
<leviroth> Multithreading old
<discocaml>
<limp.biskit> you can multi thread in any language with a unix interface, doesn’t make it very useful ()
<companion_cube>
@leviroth what's new is the ability to have multiple threads, in ocaml, running in parallel
<companion_cube>
There were threads before but they were all sharing one big runtime lock
<discocaml>
<yawaramin> it would be much simpler to have these conversations if people would assume the most charitable interpretation from the context of the question
housemate_ has quit [Remote host closed the connection]
<discocaml>
<limp.biskit> anyway, domains are the interface for multiprocessing in ocaml and they are very good.
<discocaml>
<leviroth> @companion_cube that’s fair. I don’t think eio is a good example of that distinction however.
<companion_cube>
Ah maybe not, idk.
<discocaml>
<limp.biskit> direct style schedulers are more a showcase for effects i’d say
<companion_cube>
A bit of both, but effects would be useful without domains, for sure
Serpent7776 has quit [Ping timeout: 240 seconds]
<discocaml>
<yawaramin> Eio is much more analogous to what Haskell does (green threads)
<discocaml>
<limp.biskit> almost all the code i write is still single domain but uses an effects based scheduler, it depends on the scenario which is more useful
<companion_cube>
If you mostly do IOs it makes a lot of sense yeah
<discocaml>
<limp.biskit> ah, i didn’t know haskell had green threads
<companion_cube>
Tbh they all are, miou, picos, moonpool, they all have a form of green threads/fibers
<companion_cube>
It's the natural new abstraction
<companion_cube>
Only riot does it differently because it uses the actor model instead
<discocaml>
<yawaramin> right. but i think Eio and Miou are the closest to Haskell because they also deal with concurrent I/O with the same concepts (fibers, blocking and yielding)
<dh`>
there's a popular myth that having everything mutable makes haskell parallelizable, but it doesn't work in practice
<discocaml>
<Kali> (immutable?)
<discocaml>
<Kali> and really it's not the immutability but the referential transparency (which immutability contributes to but is not interchangeable with)
<discocaml>
<Kali> but yeah either way your point stands it's not as simple as just pressing a "make parallel" button
<discocaml>
<yawaramin> darn. i was just about to press that
<discocaml>
<Kali> haha
<discocaml>
<limp.biskit> rust’s “fearless concurrency” thing is interesting