<rwmjones>
File "src/parser.mly", line 102, characters 33-37:
<rwmjones>
Error: Unbound value file
<d_bot>
<darrenldl> @Jektrix yeah not a bad idea - they are stable and lossless
<d_bot>
<darrenldl> except when you change time zone db drastically i guess, pulling the rug underneath oneself
<d_bot>
<Jektrix> Sounds like you speak from experience there
<d_bot>
<Jektrix> in what circumstances would you change timezone db
<d_bot>
<darrenldl> uh...corrupted time zone db on OS i guess
<d_bot>
<darrenldl> though timedesc doesnt use the OS copy of tzdb
<d_bot>
<darrenldl> so not really an occurrence unless you ship your own tzdb
<d_bot>
<darrenldl> just closer to a technical limitation than anything to be expected in practice
<d_bot>
<darrenldl> since the only alternative is to attach the full copy of tzdb to every timere expression for them to be 100% lossless
<octachron_>
rwmjones, I am not sure if that was intended to work before? It sounds like the best path is to either have a look at the generated code, or to use a hook that is patched to be `file` after the fact.
<octachron_>
rwmjones, it looks like it the type inference that is failing, did you try to define a dummy `let file: ... = assert false` in the header?
mbuf has quit [Quit: Leaving]
<rwmjones>
it certainly did work before, and it works with --code-ancient
<d_bot>
<cemerick> I currently use `Marshal` in certain corners, but wouldn't mind moving to something safer
Corbin has quit [Ping timeout: 268 seconds]
humasect has joined #ocaml
<d_bot>
<joris> i see. First time i see it. If there is something we don't like, it is serialization framework 😄
<d_bot>
<cemerick> the bytes must flow
mro has quit [Ping timeout: 256 seconds]
octachron_ is now known as octachron
rgrinberg has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
<companion_cube>
heh, a hot topic today
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mro has joined #ocaml
mro has quit [Ping timeout: 250 seconds]
Soni has joined #ocaml
Haudegen has joined #ocaml
humasect has quit [Quit: Leaving...]
mro has joined #ocaml
salkin-mada has joined #ocaml
waleee has quit [Ping timeout: 260 seconds]
waleee has joined #ocaml
hackinghorn has quit [Ping timeout: 256 seconds]
mro has quit [Ping timeout: 250 seconds]
rgrinberg has joined #ocaml
salkin-mada has quit [Quit: salkin-mada]
salkin-mada has joined #ocaml
salkin_mada has joined #ocaml
salkinmada has joined #ocaml
mro has joined #ocaml
keyboard has joined #ocaml
gwizon has joined #ocaml
mro has quit [Ping timeout: 256 seconds]
keyboard_ has joined #ocaml
mro has joined #ocaml
keyboard_ has quit [Client Quit]
olle has joined #ocaml
salkin has quit [Quit: salkin]
qwr has joined #ocaml
salkin has joined #ocaml
keyboard_ has joined #ocaml
keyboard_ has quit [Client Quit]
salkinmada has quit [Quit: salkinmada]
salkin_mada has quit [Quit: salkin_mada]
salkin has quit [Client Quit]
salkin-mada has quit [Quit: salkin-mada]
<d_bot>
<d4hines> I have an `Lwt_io.input Lwt_io.channel` that I'd like to read a JSON value from. What's the best way to do this? We're using `yojson` already which provides functions to do this for `Stdlb.channel`'s, but I'm not sure how to compose this with `Lwt`.
<companion_cube>
is your input a single json value?
keyboard has quit [Quit: keyboard]
<d_bot>
<d4hines> One process is sending a json value every now and then over a unix pipe to another process. So there are multiple JSON values over time, but only one at a time is sent.
Serpent7776 has quit [Read error: Connection reset by peer]
salkin has joined #ocaml
Serpent7776 has joined #ocaml
<d_bot>
<orbitz> You need some sort of delimiter between json values. Then you can just read , split in delim, and consume with yojson
salkin has quit [Client Quit]
salkin has joined #ocaml
<d_bot>
<d4hines> What would an appropriate delimiter be, considering I don't know the content of the JSON (it could have arbitrary strings)? Wouldn't this involve essentially writing a JSON parser?
<companion_cube>
delimiter, or length prefix
<d_bot>
<orbitz> Many people use new line as a delimiter, that requires the guarantee that your JSON is produced in a way without new lines
<d_bot>
<d4hines> So, first send "Hey, this is how many bytes I'm sending you", and then send the payload?
<d_bot>
<orbitz> Yes
<companion_cube>
that's one way, yes
<d_bot>
<orbitz> Both require you have control over the sender
<companion_cube>
for example, json-rpc (as used in LSP), uses http-style headers to get `content-length: <n>`
<companion_cube>
followed by n bytes of json
<d_bot>
<d4hines> I have control over the sender in this case, so I can do that.