<d_bot_>
<andreypopp> yeah... the amount of deps though... I'm looking for something to map postgresql's interval type into ocaml
<d_bot_>
<andreypopp> maybe just an integer value of seconds would work
<d_bot_>
<VPhantom> I deal with seconds when I can in my projects, yeah. It makes dealing with offsets easier and sometimes even the stdlib can be enough for converting to/from timestamps (if you happen to use UTC).
<d_bot_>
<VPhantom> The fun stuff starts when you get into day/calendar offsets because that becomes very hairy (leap years, Julian vs Gregorian, etc.)
<d_bot_>
<VPhantom> The venerable `CalendarLib` helps there if you want few dependencies.
<d_bot_>
<darrenldl> timedesc will have much fewer deps eventually...just when i have time to get to that
bartholin has joined #ocaml
waleee has joined #ocaml
<d_bot_>
<VPhantom> Oh yeah that's the one I was looking for when I thought of CalendarLib!
hannes has quit [Ping timeout: 240 seconds]
<d_bot_>
<darrenldl> some reduction will necessitate vendoring some functions within timedesc itself, which im slightly on the fence about, but i guess that'll have to be the case for a library to be usable as a fundamental lib
mro has joined #ocaml
bartholin has quit [Quit: Leaving]
szkl has joined #ocaml
<companion_cube>
ahahah ffs protobuf
<companion_cube>
I mean, the whole "required is never good" so you have comments saying "this is actually required" :D
<Cypi>
:D
<companion_cube>
they added back `optional` though
<sleepydog>
they made optional the default
infinity0 has quit [Ping timeout: 250 seconds]
<d_bot_>
<VPhantom> My main gripe is with messages for which I have to add a comment saying: "due to limitations in Protobuf this isn't declared as a 'oneof' but it MUST be treated as such".
<companion_cube>
oooof
<d_bot_>
<VPhantom> And it's not a limitation with the format, it's only with the IDL.
<d_bot_>
<VPhantom> Can't have repeated fields or maps in a oneof.
<d_bot_>
<VPhantom> Can't have ENUMs as keys in a map, either.
<companion_cube>
ah but you can wrap the fields or maps in a message
<companion_cube>
the data model isn't great
<d_bot_>
<VPhantom> Both limitations are purely in the IDL and screwed up my designs in the past.
<d_bot_>
<VPhantom> Yeah you can wrap messages in each other and everything but, having done that last month for one concept, the result is harder to work with. It's not just "ugly" it's less functional in practice.
<companion_cube>
hmm no, the data format can't let you have repeated maps I think
<d_bot_>
<VPhantom> (And, extra useless bytes in the resulting data.)
<d_bot_>
<VPhantom> Not repeated maps, no.
<d_bot_>
<VPhantom> They were two distinct limitations: can't have maps in a oneof, and can't have repeated fields in a oneof. It's the same limitation with a twist, I think.
Haudegen has joined #ocaml
<companion_cube>
yeah but it's the same root cause: a oneof must fit in a single field
<d_bot_>
<VPhantom> The format itself can perfectly well represent that, of course, but they don't want to add that complexity in the codec.
<sleepydog>
maps are just repeated fields under the covers, right?
<d_bot_>
<VPhantom> "must" is a strong word here.
<d_bot_>
<VPhantom> Repeated pairs... there's compact and non-compact, I haven't seen the details in a while…
<companion_cube>
the format can't, except by wrapping into bytes
<d_bot_>
<VPhantom> The format absolutely can: oneof is merely about enforcing the limitation.
<companion_cube>
I don't see how the format can
<companion_cube>
if maps are separate fields, that is, like sleepydog says
andreypopp_ has quit [Quit: Connection closed for inactivity]
<d_bot_>
<VPhantom> The concept of "oneof" is purely enforced in encoders and decoders, it does not affect the wire data at all.
<d_bot_>
<VPhantom> They refused to add repeated fields (and thus maps) in oneof purely to keep the encoders simpler.
<companion_cube>
I'm still not sure what you mean
<companion_cube>
for oneof to work, there must be exactly one field in it to be present
<companion_cube>
how does that work if some components have multiple fields? or 0, like an empty map?
<d_bot_>
<VPhantom> I don't understand what you don't understand… Oneof is purely a restriction on the encoding side, and it is possibly recognized on the decoding side's generated code to optimize the resulting structure a bit (like how they become variants in `ocaml-protoc`.) On the wire the message containing the oneof is structured exactly the same regardless of the oneof restriction, it just happens to only have one field set at most (and i
<d_bot_>
<VPhantom> The problem is that they want their codecs to make the further assumption that only a single field (not repeated) be present in those oneof but that is a design choice, not a format restriction.
<companion_cube>
well, if i write ocaml-protoc and have `oneof` as a sum type
<companion_cube>
I do need exactly one field to be present
<companion_cube>
(or if 0, take the default option, blabla, that sucks)
<d_bot_>
<VPhantom> One field _id_ but there's nothing preventing you from having it repeated.
<companion_cube>
I don't see how it works when you have a case that could extend on multiple fields.
<companion_cube>
yes but: empty map?
<d_bot_>
<VPhantom> `|Thing of string list` or something
<companion_cube>
and you'll never get `Thing []`
<companion_cube>
because it's interpreted by the 0 constructor instead
<d_bot_>
<VPhantom> An empty map is represented, isn't it? Hm.
<d_bot_>
<VPhantom> I already can't get empty lists on the client side though, in non-oneof messages.
<d_bot_>
<VPhantom> (proto3)
<companion_cube>
are they represented as `None` instead of `[]`?
<d_bot_>
<VPhantom> I have no idea. I never even thought of setting a repeated field explicitly to an empty list in the APIs I used before (Perl, JS)
gravicappa has quit [Ping timeout: 240 seconds]
<d_bot_>
<ansiwen> You haven't done that yet, right? I just checked, but want to make sure I'm not missing it.
<d_bot_>
<VPhantom> A repeated field is just the ability to set the field more than once (compactness aside) and codecs make it handy with list/array representations. I suppose the compact format could be used to represent an empty list? I'm rusty in those details.
<Cypi>
I don't think distinguishing an empty list from an unset field is supported, especially in proto3.
<d_bot_>
<VPhantom> That's my impression yeah.
<companion_cube>
the compact format only works for scalars
<companion_cube>
afaik
<Cypi>
(Regarding maps keyed by an enum, the reason is that representing in a language like Java with closed enums is annoying.)
<d_bot_>
<VPhantom> So from that perspective I don't see why we should necessarily forbid repeated fields in oneof.
<d_bot_>
<VPhantom> (Bah, spoils it for everyone else. 😛)
<d_bot_>
<ansiwen> Oh, you have a branch
<d_bot_>
<ansiwen> Yeah, just found it 🙂
<d_bot_>
<ansiwen> thanks a bunch... will have a look at it
<d_bot_>
<quernd> Yeah, sorry for not getting back to you on it, I think I wanted to add a README before merging but I guess you won't need that
<d_bot_>
<ansiwen> no worries, thanks a lot. since you have experience with gRPC: what do you think is the impact performance-wise compared to the http/json gateway?
<d_bot_>
<quernd> If you have lots of small requests and latency is important, you can probably benefit a lot from keeping a connection open between requests (like I did in the example)
mro has quit [Remote host closed the connection]
<d_bot_>
<quernd> You also save one roundtrip of serialization to JSON. But as always it depends, the bottleneck could be somewhere else
gravicappa has joined #ocaml
zebrag has joined #ocaml
mbuf has quit [Quit: Leaving]
infinity0 has joined #ocaml
mro has joined #ocaml
szkl has quit [Quit: Connection closed for inactivity]
<companion_cube>
but we could emit some basic traces and metrics :)
mro has joined #ocaml
mbuf has quit [Quit: Leaving]
mro has quit [Remote host closed the connection]
bobo has quit [Ping timeout: 240 seconds]
bobo has joined #ocaml
Everything has joined #ocaml
gravicappa has quit [Ping timeout: 252 seconds]
Tuplanolla has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
<sadiq>
ooh ooh
<sadiq>
we should do an eventring integration once it's merged
<sadiq>
(I was going to knock up a prometheus reporter as a proof of concept)
<d_bot_>
<undu> @companion_cube on a hackathon at citrix edwin started a similar project to get opentelemetry working ,I don't whink he posted any code though
wyrd has quit [Ping timeout: 240 seconds]
wyrd has joined #ocaml
rgrinberg has joined #ocaml
<companion_cube>
well this is starting to work for metrics and traces
<companion_cube>
conntributions welcome, etc.
<companion_cube>
(esp. for alternative collector backends! right now it's just a crappy http/ocurl thing)
<companion_cube>
sadiq: what would that look like? eventring would feed events into opentelemetry?
kaph has quit [Read error: Connection reset by peer]