<greenbagels>
I get an error about "Unbound constructor Assoc", which I figure is fair, since I don't really know how to match this Yojson.Basic.t object to an association list
<sim642>
Yojson constructors are not normal variants but polymorphic variants, so it should be `Assoc
<sim642>
The tick in front is important
<greenbagels>
oh my god it's a backtick not a single quote
<greenbagels>
this changes... everything
<greenbagels>
ok i will read more about polymorphic variants now then
<sim642>
Also, if you want to just get a few individual fields out of a Yojson value, instead of pattern matching you can use helper methods in Yojson.Basic.Util
<sim642>
Something like: our_json_data |> member "url" |> to_string
<sim642>
Assuming you open the Util module
<greenbagels>
ah i see
<greenbagels>
the Util module seems to be exactly what I'm looking for
<greenbagels>
sim642: thanks for both the tip about polymorphic variants as well as this submodule :)
shawnw has quit [Ping timeout: 250 seconds]
vicfred has quit [Quit: Leaving]
gravicappa has joined #ocaml
mro has joined #ocaml
reynir has quit [Quit: WeeChat 2.3]
reynir has joined #ocaml
Haudegen has joined #ocaml
octachron has quit [Remote host closed the connection]
octachron has joined #ocaml
<greenbagels>
does anyone have a websocket library recommendation? ocaml-websocket seems to be the biggest search result but the github repo seems to lack documentation / examples (though oddly enough, the issues reference deleted examples?)
salvi has joined #ocaml
olle has joined #ocaml
glassofethanol has joined #ocaml
hendursa1 has joined #ocaml
hendursaga has quit [Ping timeout: 276 seconds]
krnkktz has quit [Quit: Bridge terminating on SIGTERM]
mclovin has quit [Quit: Bridge terminating on SIGTERM]
marinelli[m] has quit [Quit: Bridge terminating on SIGTERM]
mewfree[m] has quit [Quit: Bridge terminating on SIGTERM]
saltrocklamp[m] has quit [Quit: Bridge terminating on SIGTERM]
schube[m] has quit [Quit: Bridge terminating on SIGTERM]
smondet[m] has quit [Quit: Bridge terminating on SIGTERM]
fluxm has quit [Quit: Bridge terminating on SIGTERM]
CodeBitCookie[m] has quit [Quit: Bridge terminating on SIGTERM]
krnkktz has joined #ocaml
fluxm has joined #ocaml
marinelli[m] has joined #ocaml
smondet[m] has joined #ocaml
schube[m] has joined #ocaml
mclovin has joined #ocaml
mewfree[m] has joined #ocaml
saltrocklamp[m] has joined #ocaml
CodeBitCookie[m] has joined #ocaml
bartholin has joined #ocaml
olle has quit [Ping timeout: 246 seconds]
orbifx has joined #ocaml
<Leonidas>
greenbagels: as a Yojson maintainer I would suggest not doing that.
<Leonidas>
`our_json_data |> member "url" |> to_string` yields brittle code since you're ignoring an number of failure cases right there: `our_json_data` not being an `Assoc, it not having a `"url"` key, and if it has one, it not being a `String.
<Leonidas>
Also, I would suggest using `Yojson.Safe.t` in any case, since that's what most of the community has converged on.
<Leonidas>
Also your code is probably doing something wrong when you use Lwt_main.run multiple times in your program.
<kakadu>
When reading Lexi's blog post I got a feeling that described approach contradict using of ppx_deriving_json and similar tools. It seems that this syntax extensions implement validation layer, which is not desired, and to do things right we need to hadle Yojson.Safe.t values manually (with a bit of error monads). What do you think?
olle has joined #ocaml
hackinghorn has quit [Remote host closed the connection]
hackinghorn has joined #ocaml
mro has quit [Remote host closed the connection]
reynir has quit [Ping timeout: 246 seconds]
reynir has joined #ocaml
bartholin has quit [Ping timeout: 252 seconds]
bartholin has joined #ocaml
[itchyjunk] has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 252 seconds]
Haudegen has quit [Quit: Bin weg.]
waleee has joined #ocaml
average has quit [Quit: Connection closed for inactivity]
<Armael>
any clues on how to debug multicore programs that appear to have a deadlock?
<companion_cube>
try to get a coredump perhaps?
<companion_cube>
or even attach gdb to the process
<companion_cube>
look at each thread's stack
<Armael>
e.g., know whether threads are blocked trying to acquire a mutex, and which one
salvi has quit [Quit: leaving]
<Armael>
yea ok
<Armael>
I've thought about gdb indeed, though now I need to learn to use gdb :-)
<companion_cube>
gdb -p <pid> iirc
<companion_cube>
then there's a command to change threads, and one to see stacktraces
<Armael>
ok, thx
<companion_cube>
also useful when you look at a coredump
<companion_cube>
(`coredumpctl gdb`)
mro has joined #ocaml
<Armael>
hmm
<Armael>
I don't know how coredumps work
<Armael>
I thought that's what you get if your program crashes with e.g. a segfault, but in my case it's just deadlocked, not crashing
mro has quit [Ping timeout: 260 seconds]
<companion_cube>
yeah, it's just a general remark
<companion_cube>
I've learnt to like coredumpd (!!!!)
<Armael>
but so what does `coredumpctl gdb` do
<companion_cube>
not applicable in your case, it's more like if you have a segfault or OOM
<companion_cube>
anyway
<Armael>
okok
fluxm has quit [Ping timeout: 264 seconds]
Haudegen has joined #ocaml
mbuf has joined #ocaml
<sadiq>
gdb is probably the best way
<sadiq>
engil is working on some thread naming stuff that will make understanding which of the threads you are looking at simpler
<Armael>
cool. fwiw my threads are tasks in a Domainslib's thread pool
mro has joined #ocaml
mro has quit [Remote host closed the connection]
<companion_cube>
also the tracing framework is good ✔ :p
<Armael>
in Domainslib.Task, what happens if I drop a promise on the floor?
<Armael>
does the thread get killed?
<companion_cube>
probably nothing? I assume it'll still compute
<Armael>
that's what I assumed as well, but now I would like to be sure ^^
<companion_cube>
well unless it cancels tasks in Gc.finalize (which would be super weird) I think you're ok
<Armael>
well yes that's what I'm afraid of
<companion_cube>
I really doubt it does that
<companion_cube>
no one sane will pick that as the default behavior :)
<zozozo>
I'd expect anything in the {do_not_compute, partially compute the task, compute the task and drop the result} continuum
<companion_cube>
really?
<companion_cube>
who the fuck does such effectful things in a GC finalizer? :D
<zozozo>
well, it's a bit like an 'a Lwt.t that you drop right after creating it, isn't it ?
<companion_cube>
which works!
<zozozo>
and if you never await for the promise to be resolved, I wouldn't blame the code for not resolving the promise...
<companion_cube>
there's Lwt.async for this very reason
<companion_cube>
and there's only one await in Lwt: Lwt_main.run
<Armael>
in my case I want threads to run forever
<Armael>
also, you guys are just speculating, so I'll go read domainslib's task.ml :p
<companion_cube>
I'm speculating based on experience with other systems :p
<zozozo>
I'm speculating based on my understanding of the documentation and what I'd expect to hold according to that
<d_bot>
<mk-fg> In python unless you await the coroutine, it doesn't run
<companion_cube>
well Task.async doesn't specify you need to hold the promise for it to complete
<companion_cube>
because it obviously runs on the thread pool anyway
<companion_cube>
@mk-fg: sure, but these are python *coroutines*, not threads/fibers/…
<d_bot>
<mk-fg> Yeah, true
<companion_cube>
coroutines need to be called, they're just glorified generators
<d_bot>
<mk-fg> Indeed
<zozozo>
companion_cube: it's true that with the `async` signature, I'd expect it to run, but... I think the pool concept is not really suited to tasks running forever, because then if you make a mistake in the number of domains for the pool, well that's not good, and you don't have any warning
<companion_cube>
zozozo: typically I'd expect that you split your main loop
<companion_cube>
like instead of `let rec loop () = … ; loop()`
<companion_cube>
you do `let rec loop() = …; Task.async loop ()`
<companion_cube>
a yield point, if you will, just like OCaml's actual loops :)
<Armael>
reading task.ml, it looks like my (and companion_cube's) intuition is right: dropping the promise does nothing
<zozozo>
companion_cube: in your example, is the call to Task.async part of the loop ?
<companion_cube>
yes
<Armael>
(the task keeps the promise alive anyway)
<companion_cube>
what a surprise
<companion_cube>
:p
<Armael>
plzzzzz
<companion_cube>
sorry, but it's like asking whether dropping a mutex on the floor unlocks it
<companion_cube>
technically it's possible, but it's just insane
<zozozo>
companion_cube: won't that end up in an unbounded number of tasks tied to the pool ?
<companion_cube>
zozozo: no, at most one step of the loop would be active at a given time
[itchyjunk] has quit [Remote host closed the connection]