package dune-rpc
sectionYPositions = computeSectionYPositions($el), 10)"
x-init="setTimeout(() => sectionYPositions = computeSectionYPositions($el), 10)"
>
Communicate with dune using rpc
Install
dune-project
Dependency
Authors
Maintainers
Sources
dune-3.22.1.tbz
sha256=0c0b98396c32ec426886c2c2294024fd687ac5114d4dda0af9dc8a2e584d47fd
sha512=4dc4ed45fb52a3017bc73fdbcb7b88c1710cebfdbb87ecb6f933582f8f0a27ef740f8c4009439ff6a878e1115c3f29d199e63d0367a88a09d2ea19b61517a814
doc/dune-rpc.private/Dune_rpc_private/Versioned/Make/Builder/index.html
Module Make.BuilderSource
Source
val declare_notification :
'state t ->
'payload Dune_rpc_private__.Types.Decl.Notification.t ->
unitA *declaration* of a procedure is a claim that this side of the session is able to *initiate* that procedure. Correspondingly, *implementing* a procedure enables you to *receive* that procedure (and probably do something in response).
Currently, attempting to both implement and declare the same procedure in the same builder will raise. While there is nothing fundamentally wrong with allowing this, it is simpler for the initial version negotiation to treat all method names uniformly, rather than specifying whether a given (set of) generation(s) is implemented or declared.
Finally, attempting to declare or implement the same generation twice will also raise.
sectionYPositions = computeSectionYPositions($el), 10)"
x-init="setTimeout(() => sectionYPositions = computeSectionYPositions($el), 10)"
>