<discocaml>
<cemerick> Is it just me, or does logs' API feel fairly overcomplicated for what it does? 🤔
<discocaml>
<cemerick> I guess the two biggest factors are it dragging formatter signatures everywhere, and then the weird little bits to help with lwt interop
<companion_cube>
it's a bit complicated if you implement reporters yourself
<companion_cube>
otherwise I find it reasonable
<companion_cube>
(I normally instantiate the `Logs.src_log` once in many modules)
<companion_cube>
but the usage is otherwise `Log.debug (fun k->k "hello %d" 42)` which is fairly simple
<discocaml>
<cemerick> companion_cube: yeah, I hadn't thought about it much until i had to write a json reporter. Right PITA tbh
<companion_cube>
:D
<companion_cube>
I'm starting to get used to it
<companion_cube>
it's very flexible
<discocaml>
<cemerick> Less than you'd think. Using formatters as it's core means that you really can't implement various non-stringy logging approaches, e.g. https://messagetemplates.org/
<companion_cube>
maybe with stags
<companion_cube>
but Logs also has its own tag system, which I don't really use
<discocaml>
<cemerick> stags? Not the same thing as logs' tags?
<companion_cube>
no, Format's stags
<discocaml>
<cemerick> Oh, right
<companion_cube>
Format has a lot of… magic features
<companion_cube>
e.g. stags can be used to add colors :)
<discocaml>
<cemerick> Yeah, ive never used semantic tags
<companion_cube>
@{<Red>howdy@}
<companion_cube>
(this works with containers btw)
<companion_cube>
I'm not sure exactly how messagetemplates would work in OCaml, I'm curious
<companion_cube>
you'd probably need a ppx and/or register printers for the fields?
<discocaml>
<cemerick> It'd be straightforward if you use yojson for the bag of attributes
<companion_cube>
oh right, so the semantic values are just json
<companion_cube>
or some fixed sum type anyway
<discocaml>
<cemerick> I think it's probably a mistake to pay all the costs to drive typesafe stuff down too close to logging ... everything is veing spit out to stderr or (at best) json ingestion anyway
<discocaml>
<cemerick> i.e. forget about custom printers, etc
<companion_cube>
or other formats for the json haters among us 🙃
<companion_cube>
(yeah, yeah)
<companion_cube>
in the API it could still make sense I suppose
<discocaml>
<cemerick> Well, is there something besides json for log sinks?
<companion_cube>
at least an equivalent of `%a` that takes a `'a -> json` and a `'a`
<companion_cube>
for 3rd party tools, aside from opentelemetry, I don't think so
<companion_cube>
for internal stuff, why not CBOR? :)
<discocaml>
<cemerick> lol ok
<companion_cube>
(opentelemetry uses protobuf)
<discocaml>
<cemerick> Can't say ive used it actually
<discocaml>
<cemerick> (At least not knowingly)
chrisz has quit [Ping timeout: 240 seconds]
chrisz has joined #ocaml
TakinOver has joined #ocaml
<discocaml>
<Scott Gráyson> I'll help anyone interested on how to earn $20k or more from the crypto market, but you will promise and agree to pay me 10% of the profit. Message me now for more information how to get started.
John_Ivan has quit [Remote host closed the connection]
<toastal>
Is Matrix now full of spam? Too popular! Time to get back to IRC and MUCs.
Serpent7776 has joined #ocaml
Serpent7776 has quit [Ping timeout: 276 seconds]
milia has left #ocaml [#ocaml]
bartholin has joined #ocaml
bgs has joined #ocaml
bgs has quit [Remote host closed the connection]
<zozozo>
companion_cube: flambda2 is working quite well; there's a bit of a feature creep because of all the extensions that we're adding, but it's managing some nice optimisations (and some more are coming)
bartholin has quit [Quit: Leaving]
hsw has joined #ocaml
<adrien>
zozozo: yeah, I'm not surprised it's faster; the alternative was not even something natural to write; and I'll see if I can try flambda2 soon (but I actually have little time available for the next ~10 days)
<adrien>
my next steps are to change the output from my modified xz from printf("%d %d %d\n", ...) to write these integers as binary since that'll make the output much smaller; and then I need to look at XZ Java to see if I can reimplement one of the match finders (actually, I need to benchmark several match finders in xz to see which ones to re-implement since I've been told the hash chains ones are similar to
<companion_cube>
zozozo: are compile times still, err, bounded? :)
<companion_cube>
I think that's what made flambda not that viable for many people
<zozozo>
companion_cube: yes, the idea is to make the default level the "classic mode", which strives to emulate closure (i.e. the regular non-flambda compiler pipeline) both in terms of compilation time and optimizations
<companion_cube>
ah yeah nice
Haudegen has joined #ocaml
rf has joined #ocaml
<discocaml>
<cemerick> Is it right that in order to get long strings to wrap within the `Format` boxes I've set up, I need to `String.iter` through their characters so as to translate e.g. linebreaks into `pp_force_newline` calls?
<companion_cube>
have you tried `pp_print_text`?
<companion_cube>
or, if there's already newlines in it, you can use CCFormat.string_lines