adrien changed the topic of #ocaml to: Discussions about the OCaml programming language | http://www.ocaml.org | OCaml 4.07.1 release notes: https://caml.inria.fr/pub/distrib/ocaml-4.07/notes/Changes | Try OCaml in your browser: http://try.ocamlpro.com | Public channel logs at http://irclog.whitequark.org/ocaml | Due to ongoing spam, you must register your nickname to talk on the channel
ShalokShalom has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
env__ has quit [Ping timeout: 252 seconds]
karlguy has joined #ocaml
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
clog has joined #ocaml
<Leonidas> mildtaste: there is an old post by rgr[m] about the differences: http://rgrinberg.com/posts/abandoning-async/
<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
r3s1stanc3 has quit [Quit: ZNC 1.7.1 - https://znc.in]
r3s1stanc3 has joined #ocaml
<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> you are right
<Leonidas> I am amazed how mseri managed to break github: https://github.com/mseri
<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]
wildsebastian has joined #ocaml
steenuil has quit [Ping timeout: 244 seconds]
Geekingfrog has quit [Ping timeout: 264 seconds]
Geekingfrog has joined #ocaml
steenuil has joined #ocaml
smasta has quit [Ping timeout: 245 seconds]
TC01 has joined #ocaml
ShalokShalom_ has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
ggole has quit [Quit: ggole]
smasta has joined #ocaml
jnavila has joined #ocaml
smasta has quit [Read error: Connection timed out]
smasta has joined #ocaml
jao has joined #ocaml
<jnavila> Hi everybody
<jnavila> I have an issue with opam.
shw has left #ocaml [#ocaml]
<jnavila> My project generates two packages, one of which depends on the other.
<jnavila> I set opam description files to match versions (version 0.4.0 of second package requires version 0.4.0 of first one.
<jnavila> But in the general opam repository, only version 0.3.0 is announced.
<jnavila> If I pin the required package locally, it still appears as v0.3.0 and the requirement fails.
JimmyRcom has quit [Ping timeout: 244 seconds]
sammie has joined #ocaml
JimmyRcom has joined #ocaml
tane has joined #ocaml
smasta has quit [Ping timeout: 245 seconds]
smasta has joined #ocaml
<smasta> Is there any way of printing the help message using Core.Command when no arguments were passed instead of erroring?
smasta has quit [Ping timeout: 244 seconds]
Haudegen has quit [Read error: Connection reset by peer]
kvda has joined #ocaml
orbifx1 has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
tane has quit [Quit: Leaving]
jnavila has quit [Remote host closed the connection]
GreyFaceNoSpace_ has joined #ocaml
GreyFaceNoSpace_ has quit [Quit: Ex-Chat]
GreyFaceNoSpace has joined #ocaml
Haudegen has joined #ocaml
bartholin has quit [Ping timeout: 246 seconds]
smasta has joined #ocaml
bartholin has joined #ocaml
Jesin has quit [Remote host closed the connection]
smasta has quit [Ping timeout: 246 seconds]
Jesin has joined #ocaml
bartholin has quit [Remote host closed the connection]
carlosdagos has joined #ocaml
spew has quit [Quit: Connection closed for inactivity]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orbifx1 has quit [Ping timeout: 245 seconds]
kakadu_ has quit [Remote host closed the connection]
smasta has joined #ocaml
MadcapJake has joined #ocaml
kvda has joined #ocaml
Haudegen has quit [Remote host closed the connection]
al-damiri has quit [Quit: Connection closed for inactivity]
smasta has quit [Ping timeout: 252 seconds]