kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
env__ has joined #ocaml
yeti119 has joined #ocaml
yeti119 has quit [Remote host closed the connection]
mfp has quit [Ping timeout: 244 seconds]
pierpal has joined #ocaml
pierpal has quit [Client Quit]
pierpal has joined #ocaml
apostolis has quit [Quit: WeeChat 1.6]
kvda has joined #ocaml
karlguy has quit [Quit: Leaving]
kit_ty_kate has quit [Ping timeout: 272 seconds]
kit_ty_kate has joined #ocaml
eagleflo has quit [Ping timeout: 240 seconds]
eagleflo has joined #ocaml
tormen_ has joined #ocaml
tormen has quit [Ping timeout: 244 seconds]
env__ has quit [Ping timeout: 244 seconds]
pzp has joined #ocaml
zv has quit [Ping timeout: 264 seconds]
keep_learning has quit [Remote host closed the connection]
env__ has joined #ocaml
env__ has quit [Ping timeout: 244 seconds]
zv has joined #ocaml
env__ has joined #ocaml
JimmyRcom has quit [Ping timeout: 244 seconds]
JimmyRcom has joined #ocaml
notnotdan has quit [Remote host closed the connection]
nullifidian_ has joined #ocaml
nullifidian has quit [Ping timeout: 252 seconds]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #ocaml
JimmyRcom has quit [Ping timeout: 244 seconds]
_whitelogger has joined #ocaml
pzp has quit [Quit: Connection closed for inactivity]
steenuil has quit [Remote host closed the connection]
Ulrar has quit [Ping timeout: 276 seconds]
Ulrar has joined #ocaml
Ulrar has quit [Ping timeout: 264 seconds]
Ulrar has joined #ocaml
zv has quit [Ping timeout: 250 seconds]
Ulrar has quit [Ping timeout: 276 seconds]
mildtaste has joined #ocaml
Ulrar has joined #ocaml
Ulrar has quit [Ping timeout: 244 seconds]
emily has quit [Ping timeout: 252 seconds]
zv has joined #ocaml
ggole has joined #ocaml
Ulrar has joined #ocaml
freyr69 has joined #ocaml
env__ has quit [Ping timeout: 272 seconds]
<freyr69>
Does lwt works different in toplevel
<freyr69>
in particular I have a problem with Lwt.on_success
<freyr69>
It seems that callback evaluates only when I rewrite a ref on thread
Ulrar has quit [Ping timeout: 252 seconds]
rand__ has joined #ocaml
Haudegen has joined #ocaml
Ulrar has joined #ocaml
nullifidian__ has joined #ocaml
nullifidian__ is now known as nullifidian
nullifidian_ has quit [Ping timeout: 244 seconds]
<Leonidas>
freyr69: utop does some magic to resolve Lwt threads in the event loop, yes.
Ulrar has quit [Ping timeout: 252 seconds]
<freyr69>
I see, yeah, it seems it works under Lwt_main.run scheduler as I expect
Ulrar has joined #ocaml
orbifx1 has joined #ocaml
bartholin has joined #ocaml
rand__ has quit [Quit: leaving]
sagotch has joined #ocaml
orbifx1 has quit [Ping timeout: 244 seconds]
rwmjones has quit [Quit: ZNC - 1.6.0 - http://znc.in]
rwmjones has joined #ocaml
kvda has joined #ocaml
rotsix has joined #ocaml
pierpal has quit [Ping timeout: 246 seconds]
keep_learning_M has joined #ocaml
pierpal has joined #ocaml
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #ocaml
carlosdagos has quit [Quit: Connection closed for inactivity]
keep_learning has joined #ocaml
keep_learning_M has quit [Quit: This computer has gone to sleep]
bartholin has quit [Remote host closed the connection]
<mildtaste>
what is the difference between async and lwt? Is there any article that explains it? From what I can grasp, async follows an event-loop model while lwt is based on threads, is that correct?
mfp has joined #ocaml
slamzy1234 has quit [Remote host closed the connection]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
erkin has quit [Remote host closed the connection]
<ZirconiumX>
mildtaste: they're both cooperative threading libraries
<ZirconiumX>
They're (almost) interchangeable
slamzy1234 has joined #ocaml
ygrek has joined #ocaml
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #ocaml
keep_learning_M has joined #ocaml
max__ has joined #ocaml
max__ has quit [Quit: Leaving]
jbrown has joined #ocaml
dx- has joined #ocaml
leah2 has quit [Ping timeout: 260 seconds]
smondet[m] has quit [Ping timeout: 260 seconds]
artart78 has quit [Ping timeout: 260 seconds]
aspiwack[m] has quit [Ping timeout: 260 seconds]
mattg__ has quit [Ping timeout: 260 seconds]
smondet[m] has joined #ocaml
aspiwack[m] has joined #ocaml
peddie1 has quit [Ping timeout: 260 seconds]
dx has quit [Ping timeout: 260 seconds]
artart78 has joined #ocaml
Haudegen has quit [Remote host closed the connection]
clog has quit [Ping timeout: 252 seconds]
keep_learning_M has quit [Quit: This computer has gone to sleep]
leah2 has joined #ocaml
peddie1 has joined #ocaml
rotsix has quit [Remote host closed the connection]
sagotch has quit [Quit: Leaving.]
mattg__ has joined #ocaml
keep_learning_M has joined #ocaml
<Leonidas>
they are almost the same apart from some slight differences in semantics
<Leonidas>
mildtaste: Lwt.t threads can "fail", which is like resolving with an error, whereas Deferred.t can't and there is special support for Deferred.Result.t (akin to Lwt_result.t)
<Leonidas>
mildtaste: also Lwt.t resolve immediately if the result can be resolved immediately, whereas Async treats all deferreds the same way.
<Leonidas>
Lwt is also commonly used with ppx_lwt, whereas Async has support for ppx_let, which works potentially with all kinds of monads
<Leonidas>
That said, I'm pretty sure async_kernel works on jsoo
spew has joined #ocaml
<mildtaste>
Leonidas: thanks for the reference, as a beginner I found the Async/Deferred model simpler to begin with, however my next step would be to implement error handling (small cli app doin a single REST api request) and from what you mentioned I should probably start looking at Deferred.Result.t to get started
<Leonidas>
mildtaste: Personally I also prefer Async these days and this is also what we use at work.
<Leonidas>
Maybe both of them will be obsoleted by diml's new framework, extracted from dune :-)
<Drup>
I doubt that, given that 1) diml works at jst 2) that's a terrible time to start a new concurency framework, given that multicore is on the way
<rks`>
I don't see what 1) has to do with anything, but I agree with 2)
<Fardale>
Multicore: soon™
<Drup>
rks`: I was going to say "don't you avoid walking on your own feet" ... but actually, no, you don't =')
<rks`>
:|
pierpal has quit [Read error: Connection reset by peer]
<xvilka>
There are some very simple PRs from multicore team that looks like weren't touched for quite a while.
<xvilka>
so progress is going on very slowly :/
<Armael>
you should accelerate progress by reviewing those!
sagotch has joined #ocaml
<xvilka>
Uh, I have zero idea about multicore internals. To me it is like tensor algebra to a primary schooler.
<xvilka>
By the way, what was decided about nicer syntax for do-like notation? For example 'let* x =...'. I cannot see any recent reference to this
silver has joined #ocaml
MadcapJake has quit [Quit: MadcapJake]
ygrek_ has joined #ocaml
ygrek has quit [Ping timeout: 244 seconds]
<freyr69>
xvilka: Actually, their progress is astonishing. I can't believe that KC and Stephen are doing all these stuff alone.
<freyr69>
this*
ygrek has joined #ocaml
ygrek_ has quit [Ping timeout: 252 seconds]
<xvilka>
freyr69: if there are only two people on it - yeah, then it is impressive.
<xvilka>
The question then why there are only two people on such vital task for OCaml community?
<Fardale>
It may not be as vital as it look like
<Drup>
xvilka: are you hiding money and highly competent *and available* compiler developers under a rock so that we can use them ? :3
<Leonidas>
Drup: I think diml was talking about that himself. Fibers, that is.
<Leonidas>
Drup: Even with multicore, Lwt and Async will not disappear overnight.
<Drup>
They won't, but if we are going to replace them with a new library, might as well do it with a multicore one
<Leonidas>
Yeah, possibly, but it is unclear that you can create a common subset for async, lwt and effects at the same time.
<Leonidas>
maybe you can? who knows.
<freyr69>
My $0.02: there are not many people like KC and Stephen, unfortunately.
<freyr69>
It took me some time to just get into what they are doing.
<freyr69>
Need to be into effects, memory models to contribute
<Drup>
Leonidas: it's already a huge pain to have a common subset for async and lwt. That's not the point anyway. It's just a terrible time to introduce a new library, known that we will have a new, better paradigm in a few years
<companion_cube>
+probably
<xvilka>
Fardale: not sure how it is not vital when all "competitor" languages have this one way or another.
<companion_cube>
except for almost all the dynamic languages?
sagotch has quit [Ping timeout: 250 seconds]
sagotch has joined #ocaml
<freyr69>
Which are not OCaml's competitors, though.
<companion_cube>
are they not? what are OCaml's competitors then?
<companion_cube>
(I suppose SML has at least one multicore implem, so the closest competitors does have it indeed)
<freyr69>
companion_cube: The reason is simple: OCaml has no libraries, nobody would choose it over python in python's domain
<freyr69>
competitors are Java, Scala, Haskell, Go
<freyr69>
maybe D
<companion_cube>
depending on what you do, I'm pretty sure single-core OCaml can be faster than multicore java :p
<companion_cube>
(especially for CLI apps, but well)
<freyr69>
Java is fast, even startup is quite fast, really. Maybe it's not as effective for apps like grep, but still. It's also quite good in unboxing nowadays.
<xvilka>
Also Rust
roygbiv has joined #ocaml
<xvilka>
Java is hardly a competitor, imho
<companion_cube>
I wouldn't count 500ms as "fast".
<companion_cube>
yeah rust is cool, it's harder to learn than OCaml though
<freyr69>
Well, Rust is painful, so at least OCaml has an advantage.
<companion_cube>
I'm not against multicore but I do think its importance is overestimated
<zozozo>
freyr69: I'm not really convince java is fast, particularly, startup can be costly (I remember some benchmarks where I beat java programs mainly because of that, :p )
<xvilka>
and of course you forgot F#
<companion_cube>
(ie the use cases where it can bring a non trivial perf boost are quite rare)
<xvilka>
but it has the similar problem as OCaml
<xvilka>
afair
<freyr69>
companion_cube: Dunno, pretty all tasks in my domain are parallelable
<freyr69>
Not to mention new and shiny ``bigdata'' and machine learning stuff.
<freyr69>
You could use processes though
<freyr69>
I agree that it's overestimated a bit, what we really need is libraries which could utilize hardware capabilities (FPGA, GPU, cores) in the idiomatic OCamlish way
<freyr69>
First two are achievable, but lack of multicore impedes multicore utilization
<companion_cube>
freyr69: funny, none in my domain are parallelizable
<companion_cube>
even when algos are parallelizable, it's not trivial to actually gain speed if you have synchronization overhead
<companion_cube>
(so, unless it's "embarrassingly parallel", the benefit is not immediate and not obvious)
<freyr69>
Sometimes you don't need to parallelize your algorithm
<xvilka>
ML is totally different thing, they are moving towards ASICs
<companion_cube>
freyr69: "big data" and stuff needs GPU binding, not CPU multicore
<freyr69>
sometimes you nedd tasks
<xvilka>
so probably better to skip the GPU thing at all
<Drup>
Parallelizing compilers/static analyzer is a long standing question :)
<companion_cube>
ie it's hard as fuck
<companion_cube>
also, we could try to have SIMD before even thinking about multicore? and better cache behavior?
<Drup>
You can't push expressivity, linear efficiency *and* parallelization at the same time :p
<companion_cube>
cause these stand for 10× perf gains in tight loop
<companion_cube>
multicore, rarely so
<freyr69>
for example if I need to decode frame, process it and then encode, I have a clear win with threads
<freyr69>
that's what pretty much any multimedia framework does
<companion_cube>
yeah and I'd never write that in OCaml, when rust exists…
<freyr69>
Ada's tasks are also widely used to orchestrate, well, tasks
<companion_cube>
they're just threads with different synchronization primitives, are they not?
<freyr69>
As a person, who had wrote it in rust, I tend to disagree
<freyr69>
written*
<freyr69>
yes
<freyr69>
they are
<companion_cube>
why? rust is perfect for writing such libraries
<companion_cube>
and OCaml for low level array manipulation is… not that great
<xvilka>
also with Rust Formalization workgroup's work the need of Ada/SPARK is diminishing
<freyr69>
Sure, for simple plugins, not for gluing things together. I.e. I'd prefer to write decoder in rust or ada, but to glue decoder, postproc and encoder together with OCaml
<companion_cube>
Ada seems pretty cool, but its syntax and the compiler that stayed closed for years killed it for mainstream
<companion_cube>
freyr69: you can do that I think, there's ocaml-rs
<companion_cube>
(although linking is a PITA)
<freyr69>
But no threads
<companion_cube>
the rust function calls could release OCaml's lock, I suppose
<freyr69>
We use rust + ocaml already, just run them in separate processes and use IPC
<companion_cube>
(I wonder, also: isn't that another domain where multicore OCaml is not even as important as SIMD OCaml?)
<freyr69>
I could write simd OCaml library or use something like OWL
<Drup>
freyr69: wouldn't have an issue with the FFI cost for simd in ocaml ?
<Drup>
(also, there are lot's of various other issues, but that's an annoying one)
<ggole>
OCaml data representations don't really play nice with SIMD
<freyr69>
Well, I could use threads releasing gil, but I'd rather not to
<freyr69>
Bigarray?
<Drup>
ggole: yes, that's one of the "various other issues"
<Drup>
freyr69: too heavy weight
<freyr69>
In what sense?
<Drup>
in all the senses :D
<Drup>
(2 pointers indirection to access them, data layout is imposed to something flat, can't be touched by the GC ...)
<Drup>
freyr69: honestly, sentences like "I could write simd OCaml library" strikes me as "I have not looked at the problem closely" ;)
<Drup>
(I would be happy to have one so if you are motivated, go! but it's far from "easy")
<freyr69>
Drup: Sure, by simd library I meant use bigarrays + logic written in C-compatable lang
<Drup>
yeah, you will barely get any perf out of that.
<freyr69>
In case of SIMD most definitely the overhead cost would eat all benefits
<freyr69>
Haskell somehow have all sorts of unboxed datatypes, I hope one day there would be something beyond Floatarray in OCaml
_mseri_ has joined #ocaml
<ggole>
The GC isn't really designed for it
<_mseri_>
Leonidas: don't tell me... there is still no timeline for the fix
<Drup>
_mseri_: how did you do it ?
<_mseri_>
No idea
<Drup>
:D
<_mseri_>
I did run dune-release but I think it was already broken before that
<Drup>
_mseri_: are you the one responsible for the downtime a few day ago ?!
<_mseri_>
don't tell anyone ;)
<Drup>
!
<_mseri_>
At least the repos are still accessible...
<_mseri_>
I just have to remember their names
<_mseri_>
And the PRs are working also, only the one to opam-repository is badly broken
<Drup>
impressive
<_mseri_>
I have a sort of HeisenGitHub profile now, I wonder if it's the only one
<Drup>
Can you still push to your branches ?
<Drup>
Ah yeah, the repo works, it's only the profile
<companion_cube>
tbh OCaml isn't really designed for modern CPUs
<Drup>
companion_cube: modern CPUs are not designed for programming languages :D
<companion_cube>
and its take on polymorphism isn't well suited anyway
<companion_cube>
Drup: agreed, no language is really fit for them, but some are more fit than others
<_mseri_>
companion_cube what do you mean with its take on polymorphism?
<_mseri_>
What is wrong with it?
<ggole>
It uses the same code to range over all types
<companion_cube>
well, it requires runtime polymorphism (that functions are truly polymorphic, I mean)
<ggole>
Which means everything is one word, either an immediate or a pointer
<companion_cube>
^
<freyr69>
Doesn't flambda do function monomorphisation?
<ggole>
And there's polymorphic recursion and polymorphic fields, so there's not much you can do about that
<ggole>
Functions aren't the only place where the problem appears
<ggole>
Datatypes also contain values
<ggole>
And the issue is arguably worse there
<_mseri_>
Oh, I see. Thanks
<ggole>
You could add special datatypes which a type variable could not range over
<companion_cube>
freyr69: it's unpredictable
<Drup>
Bleh, it's okay. But it solves a different issue
<Drup>
flambda only changes code, not memory layout
<freyr69>
Well, it needs the notion of unboxed sized variables
<ggole>
In fact, there's probably an interesting approach with sized kinds, in which instead of byte arrays you have an '8 array type and can put any type which fits in 8 bits in there
<ggole>
Then you don't lose all polymorphism
<ggole>
And still don't have to duplicate code for every possible type
<ggole>
But that's not how OCaml is designed
<Drup>
ggole: I can hear principality explodes in the background
<ggole>
Oh, yes. It flies out the door and you never see it again.
<Drup>
(that being said, it's very cute)
<freyr69>
Can't you just make all types sized or pointer, and then allocate statically? I.e. value types, or something like that?
<ggole>
If you want low level programming in an ML, I think you would do it that way
<ggole>
Otherwise I suppose you're just Rust with a GC
<ggole>
freyr69: (real) polymorphism poses a problem for that
<ggole>
You can do that in SML (and MLton does pretty much exactly that), but not OCaml
<freyr69>
Couldn't Mlton do all sorts of such stuff (though at the cost of global analysis)? Could there be a sweet spot in between?
<freyr69>
ggole: you mean stuff like 'a -> 'a? Or what?
<ggole>
This is because polymorphic recursion was deliberately left out of SML in order to allow full specialisation as an implementation technique
<ggole>
freyr69: { f : 'a. 'a -> 'a -> int }, for instance
<ggole>
The field f can be called at any type
<freyr69>
ggole: can't you just force boxing for such cases especially?
<ggole>
I don't think so, you don't know the size/tag for the boxee when you are compiling f
<ggole>
It might be possible with some trickery, though
<ggole>
eg, I believe F# does it with runtime compilation
Guest76590 has joined #ocaml
freyr69 has quit [Remote host closed the connection]
Guest76590 has quit [Remote host closed the connection]
Haudegen has joined #ocaml
JimmyRcom has joined #ocaml
labdog has joined #ocaml
labdog has quit [Client Quit]
slamzy1234 has quit [Ping timeout: 256 seconds]
regnat[m]1 has quit [Ping timeout: 250 seconds]
h11[m] has quit [Ping timeout: 250 seconds]
dx- is now known as dx
_mseri_ has quit [Quit: Page closed]
isaachodes[m] has quit [Ping timeout: 252 seconds]
regnat[m]1 has joined #ocaml
h11[m] has joined #ocaml
isaachodes[m] has joined #ocaml
kakadu has joined #ocaml
al-damiri has joined #ocaml
emily has joined #ocaml
bartholin has joined #ocaml
Haudegen has quit [Remote host closed the connection]
ShalokShalom_ has joined #ocaml
sagotch has quit [Quit: Leaving.]
roygbiv has quit [Quit: ™]
TC01 has quit [Ping timeout: 240 seconds]
Haudegen has joined #ocaml
smasta has joined #ocaml
steenuil has joined #ocaml
kakadu_ has joined #ocaml
wildsebastian has quit [Ping timeout: 264 seconds]