<octachron>
the constraint "OpamPackageName : Printable" makes OpamPackageName.t abstract (and unusable)
<Leonidas>
ah, adding the sharing constraint there helps
mro has quit [Remote host closed the connection]
<Leonidas>
thanks :)
sheb has quit [Quit: Leaving]
slothby has joined #ocaml
rgrinberg has joined #ocaml
gravicappa has joined #ocaml
xiongxin has joined #ocaml
xiongxin has quit [Client Quit]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
spip has joined #ocaml
zebrag has joined #ocaml
mro has joined #ocaml
salkin has quit [Ping timeout: 252 seconds]
Haudegen has quit [Quit: Bin weg.]
bartholin has quit [Quit: Leaving]
<d_bot>
<cemerick> I was digging around after dealing with a well-hidden exception that was occurring in an lwt promise, and came across this https://github.com/ocsigen/lwt/issues/840
<d_bot>
<cemerick> > Another confusing thing is that stack trace propagation with Lwt currently only happens when using lwt_ppx by producing calls to Lwt.backtrace_bind. This is not the case with >>= and the new (let*) operators. In addition to that the docs for Lwt_ppx hide the fact that the ppx will produce better traces.
<d_bot>
<cemerick> suffice it to say, I leaned back and literally said "oof" 😬
mro has quit [Remote host closed the connection]
Techcable_ is now known as Techcable
rgrinberg has quit [Ping timeout: 256 seconds]
<d_bot>
<cemerick> is it so crazy to think that operators should themselves be potential ppx extension points? Seems like absent some mechanism for intervention like that, the above is sort of intractible.
rgrinberg has joined #ocaml
rgrinberg has quit [Client Quit]
<companion_cube>
you can redefine (let*) to be backtrace_bind
<companion_cube>
I don't know why it's not the case
Anarchos has joined #ocaml
glassofethanol has quit [Quit: leaving]
mbuf has quit [Quit: Leaving]
Haudegen has joined #ocaml
Guest1723 has joined #ocaml
Guest1723 has quit [Ping timeout: 256 seconds]
waleee has joined #ocaml
Corbin has quit [Ping timeout: 265 seconds]
Corbin has joined #ocaml
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 256 seconds]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
waleee has quit [Quit: WeeChat 3.3]
waleee has joined #ocaml
Tuplanolla has joined #ocaml
rgrinberg has joined #ocaml
Serpent7776 has quit [Quit: leaving]
<rgrinberg>
companion_cube why do you want to re-export lwd from nottui?
<companion_cube>
o/
<companion_cube>
to only have to care about one module.
<companion_cube>
this needs to be as fluent as possible
<companion_cube>
btw /j #lwd :)
<rgrinberg>
I don't think it's a good idea. it is notoriously confusing for tooling and navigation
<rgrinberg>
you end up having to goto definition twice everywhere, the docs are duplicated, compilation slows down
<companion_cube>
compilation would slow down imperceptibly
<rgrinberg>
I think the slow down is proportional to the size of the interface of Lwd :)
<companion_cube>
yeah and it's tiny
<rgrinberg>
Anyway, it's just my experience from working with async/core which insist on re-exporting everything everywhere.
<companion_cube>
btw, since you're here: is there an equivalent of @check that doesn't try to compile non-installable stuff?
<rgrinberg>
It's awful and creates a maze
<companion_cube>
(ie doesn't try to compile benchmarks and other things)
spip has quit [Quit: Konversation terminated!]
<rgrinberg>
it depends on how your organized your sources
<rgrinberg>
if you have a directory that includes everything but the benchmarks you could do dune build @src/check
<companion_cube>
here it's in the context of yojson, and opam-ci
<rgrinberg>
But usually in this case I just let the check fail on the benchmarks repeatedly
<companion_cube>
ocaml-ci? whatever
<rgrinberg>
hmm so why do you run @check in ci?
<companion_cube>
idk, it seems to be part of ocaml-ci
<rgrinberg>
no idea then, but you do lose out if the benchmarks aren't tested with @check, no?