<Tekk_>
Is it possible to derive show on multiple types in a module? I've got a couple of mutually recursive types which would be nice to pretty print and (afaik?) there's no way to have mutually recursive types in different modules.
<Tekk_>
nvm, it just handles it.
malc_ has joined #ocaml
inkbottle has joined #ocaml
zebrag has quit [Read error: Connection reset by peer]
dborisog has joined #ocaml
sagax has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
sagax has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has joined #ocaml
mbuf has joined #ocaml
malc_ has quit [Ping timeout: 240 seconds]
malc_ has joined #ocaml
vicfred_ has quit [Quit: Leaving]
inkbottle has quit [Read error: Connection reset by peer]
inkbottle has joined #ocaml
shmibs has quit [Quit: leaving =o]
nullcone has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has joined #ocaml
narimiran has joined #ocaml
mbuf has quit [Ping timeout: 246 seconds]
osa1 has joined #ocaml
mbuf has joined #ocaml
sarna has joined #ocaml
waleee-cl has joined #ocaml
terrorjack has quit [Ping timeout: 244 seconds]
terrorjack has joined #ocaml
def has quit [Remote host closed the connection]
def has joined #ocaml
Haudegen has joined #ocaml
sarna has quit [Quit: Connection closed]
sarna has joined #ocaml
dckc has quit [Ping timeout: 260 seconds]
dckc has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has joined #ocaml
ipavlo has quit [Read error: Connection reset by peer]
malc_ has quit [Remote host closed the connection]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
shmibs has joined #ocaml
gahr has quit [Remote host closed the connection]
gahr has joined #ocaml
sarna has joined #ocaml
rockethead has joined #ocaml
rockethead has quit [Client Quit]
nullcone has quit [Quit: Connection closed for inactivity]
waleee-cl has quit [Quit: Connection closed for inactivity]
sarna has quit [Ping timeout: 246 seconds]
<Leonidas>
hmm, is it expected that dune does not update opam files on `dune build @all`?
<zozozo>
Leonidas: it might only be build with dune build @install ?
malc_ has joined #ocaml
<Leonidas>
Yes, that seems to be the case
<Leonidas>
Unfortunately the docs don't state which @target specifically writes opam files
<zozozo>
yeah, the one thing that annoys me with dune is I can never understand how the targets work (as in how to build a particular executable for instance)
sagax has quit [Remote host closed the connection]
<Fardale>
zozozo: for a particular executable: dune build path/to/main/module.exe
malc_ has left #ocaml ["ERC (IRC client for Emacs 28.0.50)"]
<Leonidas>
Fardale: In theory I know that, but in practice I find it easy to forget, especially the `.exe` part requires me to know how dune will name the targets.
brown121407 has joined #ocaml
<Leonidas>
given `.exe` is not a common file extension on unix to begin with
<Fardale>
I agree, it took me some time to get use to it
<Fardale>
Then you add the public executable or not and it get really hard
<zozozo>
I also always forget the leading ./ when the target is in the current dir
jco has joined #ocaml
kleisli_ has quit [Ping timeout: 246 seconds]
vicfred has joined #ocaml
gareppa has joined #ocaml
gareppa has quit [Remote host closed the connection]
<jco>
Hello!
<jco>
so tge quick fix to conform to the new lwt.async signature breaks the server
<jco>
that is we used the old ltw.async signature which was (unit -> 'a Lwt.t) -> unit
<jco>
which became (unit -> unit Lwt.t) -> unit
<jco>
so i append |> fun _ -> Lwt.return () to the functions given to async, so that they get the good signature: unit -> unit Lwt.t
<jco>
but it looks like our server is blocked, as if the promises which evaluated to errors aren't ignored
<Fardale>
What did this breaks?
<jco>
the server doesn't respond to client requests
<jco>
it doesn't print any error
<jco>
(we set Lwt.async_exception_hook to print unhandled errors)
<Fardale>
What do you do in the async function?
<Leonidas>
jco: you should probably use `>>= fun _ -> Lwt.return ()` instead
<jco>
we send answers to the clients
<jco>
oh yeah
<Leonidas>
since you want to bind on that 'a promise and replace it with a unit promise
<jco>
because we're manipulating promises
<jco>
right
<Fardale>
oh right I did not catch this
<jco>
ahh that's bad
waleee-cl has joined #ocaml
<Leonidas>
Personally I am somewhat concerned about stuff that's just Lwt.async'd away
<jco>
yeah, but the promises are just the results of server requests
<jco>
thanks for the catch
<Leonidas>
and the server does not want to have the result? why would the result be a `unit`?
<jco>
i agree that if there are errors, then connectivity is really bad, and the server should shut down
<Leonidas>
I would expect a handler to be Request.t -> Response.t Lwt.t or something like that.
Haudegen has quit [Quit: Bin weg.]
dckc has quit [Ping timeout: 272 seconds]
dckc has joined #ocaml
govg has joined #ocaml
Anarchos has joined #ocaml
<jco>
Leonidas: the answers are wrapped in tuples of primitive types that store the relevant info, which we then analyse
<jco>
but async requires a function which yields a unit Lwt.t
<Leonidas>
so, did my solution fix your issue?
<jco>
yes, thank you :)
<jco>
the fix i had simply "dropped" the promises
<jco>
i was relying to much on ocaml type checker ^^
<Leonidas>
yeah, that's sort of the problem with the type system that it won't warn you on such things
<Leonidas>
in the case of Lwt it might actually work some of the time since the promises are evaluated eagerly
<Leonidas>
so dropping them might work just fine since they are already resolved
narimiran has quit [Ping timeout: 258 seconds]
govg has quit [Quit: leaving]
<jco>
yeah, except they were not evaluated yet to block the server like that :)