rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Haudegen has quit [Ping timeout: 256 seconds]
Tuplanolla has quit [Quit: Leaving.]
infinity0 has quit [Ping timeout: 240 seconds]
infinity0 has joined #ocaml
waleee has quit [Ping timeout: 256 seconds]
waleee has joined #ocaml
infinity0 has quit [Remote host closed the connection]
perrierjouet has quit [Quit: WeeChat 3.4]
infinity0 has joined #ocaml
perrierjouet has joined #ocaml
rgrinberg has joined #ocaml
waleee has quit [Ping timeout: 240 seconds]
hackinghorn has quit [Quit: Leaving]
gravicappa has joined #ocaml
mbuf has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
hackinghorn has joined #ocaml
hackinghorn has quit [Changing host]
hackinghorn has joined #ocaml
hackhorn has joined #ocaml
hackinghorn has quit [Ping timeout: 240 seconds]
hackhorn is now known as hackinghorn
hackinghorn has quit [Changing host]
hackinghorn has joined #ocaml
<hackinghorn>
hi
<dmbaturin>
Hi hackinghorn!
<hackinghorn>
is "begin..end" the same as "(..)"
<hackinghorn>
hello friend dmbaturin !
<dmbaturin>
In most cases, yes. But there are edge cases... `let begin end = ...` causes a syntax error.
<dmbaturin>
But where it can be parsed, it's the same as `( )`.
<dmbaturin>
`print_newline begin end`
<d_bot>
<leaf> i'd like to write a program which spawns a subprocess and regularly communicates with it by writing to its stdin/reading from its stdout. what would be the best way to do that in ocaml? is Unix enough or do i have to use libraries like Lwt/Async
<rgrinberg>
Unix is enough if your communication is synchronous
hackhorn has joined #ocaml
hackinghorn has quit [Ping timeout: 240 seconds]
<dmbaturin>
If there are multiple subprocesses and you want to poll them, there's Unix.select
hornhack has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
<dmbaturin>
But if it's just one subprocess, then you can just do Unix.open_process_full and read/write to the descriptors it gives you.
<hackinghorn>
what is better/preferred? "List.iter ~f:(fun [long ......]) listl" or "List.iter listl ~f:(fun [long ......])"
<d_bot>
<leaf> nice, thanks
<hackinghorn>
dmbaturin, wow I'm gonna steal that
hackhorn has joined #ocaml
hackinghorn has quit [Ping timeout: 240 seconds]
hackhorn is now known as hackinghorn
hackinghorn has quit [Changing host]
hackinghorn has joined #ocaml
<hackinghorn>
dmbaturin, I'm back to steal your code
xd1le has joined #ocaml
x88x88x has quit [Remote host closed the connection]
x88x88x has joined #ocaml
bartholin has joined #ocaml
mro has joined #ocaml
Haudegen has joined #ocaml
<hackinghorn>
if I have function definition inside a loop like "List.iter ~f:(let func a b c = ... in ...) listl", is it very bad? How bad is it?
<zozozo>
hackinghorn: what do you mean by "bad" ? Personally, I'd say it's mainly not a great style for code, but apart from that..
<hackinghorn>
like, will it increase runtime? increase exe file size? will it affect things negatively? by a lot?
<hackinghorn>
also, is it frowned upon?
<hackinghorn>
I can guess its frowned upon
mro has quit [Remote host closed the connection]
mro has joined #ocaml
szkl has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
reynir has joined #ocaml
spip has quit [Quit: Konversation terminated!]
spip has joined #ocaml
mro_ has joined #ocaml
mro has quit [Ping timeout: 256 seconds]
mro_ has quit [Remote host closed the connection]
mro has joined #ocaml
Tuplanolla has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hackinghorn has quit [Quit: Leaving]
spip has quit [Ping timeout: 240 seconds]
bobo_ has joined #ocaml
<d_bot>
<zakkor> i don't think it matters too much
cedric has joined #ocaml
<zozozo>
it shouldn't be too bad; however, if the function you use to filter elements (i.e. the `let func a b c = ... in ...`) can be defined outside the loop it would improve performance at runtime, since that way the closure will not need to be reallocated at each loop
gravicappa has quit [Ping timeout: 240 seconds]
gravicappa has joined #ocaml
kurfen has quit [Ping timeout: 250 seconds]
kurfen has joined #ocaml
mro has quit [Remote host closed the connection]
<hannes>
with dune and ocamllex & ocamlyacc, how do I figure out which rule caused issues? I see the error "1 rule never reduced ; 1 shift/reduce conflict". any ideas?
<dmbaturin>
hannes: I usually just run menhir by hand with debug options.
<dmbaturin>
Well, ocamlyacc in your case.
hackinghorn has joined #ocaml
<hannes>
dmbaturin: thanks, indeed that worked nicely
hackinghorn has quit [Remote host closed the connection]
hackinghorn has joined #ocaml
mro has joined #ocaml
hackinghorn has quit [Read error: Connection reset by peer]
hackinghorn has joined #ocaml
<d_bot>
<leviroth> One problem with writing `List.iter ~f:(let func a b c = ... in ...)` is that `f` will be subject to the value restriction
<d_bot>
<leviroth> zozozo: I don't see why there would be any difference in allocation.
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
cedric has quit [Quit: Konversation terminated!]
<d_bot>
<leviroth> (of course re: value restriction I'm not sure where in practice you would need this particular line of code to be polymorphic)
<d_bot>
<Bluddy> yeah nobody's touching that until multicore is integrated
hackinghorn has quit [Ping timeout: 256 seconds]
gravicappa has joined #ocaml
<d_bot>
<VPhantom> Speaking of multicore, I notice it reimplements `Lazy`, but the new documentation still warns of possible issues when forcing across domains. I still don't fully understand what "thread-safety" means for this purpose. Is it risky to use lazy with OCaml 4.x and `Lwt` cooperative threading? Will servers made with Lwt benefit from domains, and if so, still pose risks for using lazy? (Basically: should I continue to avoid using lazy
<d_bot>
<VPhantom> (I might've asked in #lwt but I think what I fail to understand is fundamental to `Lazy`.🤔)
<d_bot>
<VPhantom> As far as I know, I'd want for the concurrent domains to wait for the resolution instead of raising `RacyLazy`…
<d_bot>
<octachron> OCaml 5.0 will not include `RacyLazy` and it will be the responsibility of the user to lock the lazy value during forcing.
<d_bot>
<VPhantom> I guess I should read up on `Thread` vs `Lwt`. It's confusing as `Thread` is defined as a "lightweight thread" and that's pretty much how `Lwt` also describes itself. I think these days POSIX threads are managed by the kernel instead of being faked in-process like the good old days of MIT pthreads (`setjmp()` and `longjmp()`). AFAIK Lwt is a single thread in a single process, which runs various continuations in a loop, whereas `
<d_bot>
<VPhantom> I wouldn't have a clue how to do that…
<dmbaturin>
Lwt switched its "thread" terminology to "promise" to avoid confusion a while ago.
<d_bot>
<octachron> The warning refers to domain (which are a group of OS threads + some metadata) which are the unit of parallelism in OCaml 5.
<d_bot>
<VPhantom> And `Thread` refers to OS threads, distinct stacks in a single process but managed by the kernel?
<d_bot>
<VPhantom> My main goal is just to make sure that what I'm writing now will still work as expected if/when used in a web service which, presumably, will end up using multiple cores later (albeit always serve a single request on a single core).
<companion_cube>
Don't share lazy values between cores, probably
<companion_cube>
That's my takeaway
<d_bot>
<VPhantom> Ah ha, so I shouldn't shy away from using them inside a Lwt process then.
<d_bot>
<octachron> `Thread.t` are OS threads but only a single thread by domain runs in parallel. Normally, you can mostly assume that any code that works with current OCaml will still work in OCaml 5 (but without any implicit benefits)
seeg has joined #ocaml
<d_bot>
<VPhantom> Makes sense. I never had a need for actual threads (just Lwt which I guess is even simpler). I just want to make sure that when Lwt (or other) spreads over multiple processors, I'll still have the same behavior I have now with fully independent processes. Looks like yes.
humasect has quit [Quit: Leaving...]
<d_bot>
<VPhantom> (I should also read up on why web services like cohttp and httpaf use cooperative threads like Lwt/Async instead of full-blown `Thread.t`. I assume it's because I/O bound switching is cheaper inside a single actual thread.)
dalek-caan has joined #ocaml
<Leonidas>
I also assume that you just need fewer syscalls
mro has joined #ocaml
mro has quit [Ping timeout: 256 seconds]
<d_bot>
<leviroth> I assume at least some of it is a preference for the monadic style and not just performance
kakadu has quit [Remote host closed the connection]
mbuf has quit [Quit: Leaving]
<dmbaturin>
Is there a way to make opam set up shell configs without doing a full `opam init`?
<d_bot>
<NULL> It's adding a hook to a file in .opam, so how could it do it if the file doesn't exist
<dmbaturin>
Oh, I mean just add the line to the shell config.
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
<dmbaturin>
I found it already, `opam init --shell-setup`.
romildo has joined #ocaml
Haudegen has joined #ocaml
<d_bot>
<NULL> Doesn't this just automatically answer yes to the question ? I'm not sure this skips anything
<dmbaturin>
It may. I only wanted to restore the shell config, the opam setup itself is fine.
<d_bot>
<NULL> In any case, you can re-execute opam init fine if you already did, it will re-ask for the hooks but won't redo the initialization
<d_bot>
<VPhantom> From what I can tell, promises vs systhreads avoids some pitfalls of actual threads and is at least as performant for I/O bound applications. So it's an easy choice for me, especially now that we have let bindings which make the overhead of `Lwt_result.t` disappear cleanly.
<companion_cube>
You can use lwt_domain to dispatch cpu tasks to the background, too
<d_bot>
<VPhantom> I wouldn't dare. 😛
<companion_cube>
It's pretty safe afaict?
<d_bot>
<VPhantom> One has to become acutely aware of who owns what bits of memory, there's mentions of locking and what not, and I'm not sure how the multicore GC handles that in practice. It's not something I'd attempt without some serious prior RTFM.
tomku has quit [Read error: Connection reset by peer]
tomku has joined #ocaml
<companion_cube>
Well it's going to be useful with multicore, for stuff like decoding json on the thread pool
<companion_cube>
No locking needed if you work with values
romildo has quit [Quit: Leaving]
<d_bot>
<VPhantom> You mean a domain pool?
<d_bot>
<VPhantom> You highlight a good point in favor of pre-emptive threading though: one thread per request, no need to extract computations.
<rgrinberg>
companion_cube how much json does one need to decode to justify that overhead?
<d_bot>
<VPhantom> I know in a single thread on my laptop Yojson can pump through something like half a gig per second, so I'm not worried about that for what we do. 😉
<rgrinberg>
i meant that it wouldn't even necessarily speed anything up unless the json packets are pretty big. synchronization across cores isn't free
<d_bot>
<VPhantom> (Sorry I guess it's 133MB/sec on my laptop; just double-checked.)
<rgrinberg>
That could probably be sped up quite a bit if you write bindings for one of the C json libraries out there
<d_bot>
<VPhantom> It's already well beyond the minimum performance requirement I have for our next-gen web site to handle 10x the traffic we have right now.
<d_bot>
<VPhantom> (Ours is an Apache/mod_perl site. OCaml is 20x faster without even trying…)
<rgrinberg>
i'm sure. i've yet to see a webapp bottle necked by json parsing speed
<companion_cube>
rgrinberg: idk
<d_bot>
<VPhantom> That said we'll use Protobuf in binary mode for our internal I/O; that's 6x faster for the same payload in my benchmarks.
<d_bot>
<VPhantom> (That's ocaml-protoc; I have yet to add the newer ocaml-protoc-plugin to my benchmarks.)
<rgrinberg>
lol mod_perl
<d_bot>
<VPhantom> Yeah well, we started writing it in 2003, from existing CGIs from the year before, so "legacy"…
<d_bot>
<VPhantom> That's when we thought the likes of Amazon would propel mod_perl to the forefront.
<rgrinberg>
there's ocaml-pb, which is very cleanly written and plays well with async
<rgrinberg>
if I wanted perf, I'd write bindings to upb though
<d_bot>
<VPhantom> Java "JSP" probably would've been the safest long-term bet, but the HotSpot JIT was still pretty lackluster back then.
<companion_cube>
What's upb?
<d_bot>
<VPhantom> Hm, why haven't I considered `ocaml-pb`? (or perhaps eliminated it) 🤔
<companion_cube>
Also you could write a decoder in C and bind it
<rgrinberg>
companion_cube really fast pb implementation in C
<companion_cube>
Protobuf isn't that complicated
<companion_cube>
Heh ok
<d_bot>
<VPhantom> Hm ocaml-pb seems to be lower-level vs the two others, and it doesn't implement the JSON side.
<d_bot>
<VPhantom> Bindings to `upb` could be nice. I always shied away from any FFI but that could be worthwhile.
<rgrinberg>
companion_cube they have cmake as well don't they?
travv0 has joined #ocaml
<companion_cube>
"experimental"
<companion_cube>
Well, anyway. Good to know.
<companion_cube>
There's also a rust implementation somewhere
<rgrinberg>
i mean, if i was serious about using it, I would write a dune port anyway :)
<d_bot>
<VPhantom> Using upb is more than FFI though, there'd need to be a runtime on the OCaml side, a conversion to useful types, etc.
<d_bot>
<VPhantom> "While upb offers a C API, the C API & ABI are not stable. For this reason, upb is not generally offered as a C library for direct consumption, and there are no releases." — Doesn't look like something to rely on just yet.
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hackinghorn has joined #ocaml
dalek-caan has quit [Quit: dalek-caan]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
Haudegen has joined #ocaml
mro has joined #ocaml
gravicappa has quit [Ping timeout: 240 seconds]
kaph has quit [Read error: Connection reset by peer]
kaph has joined #ocaml
spip has joined #ocaml
bobo_ has quit [Ping timeout: 256 seconds]
Everything has joined #ocaml
bartholin has quit [Quit: Leaving]
rgrinberg has joined #ocaml
jlrnick has joined #ocaml
Haudegen has quit [Ping timeout: 252 seconds]
Haudegen has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]