Holochain Forum


For now, Tryorama-RSM lives here: https://github.com/holochain/tryorama/tree/rsm. As per its README, it is in a transitional stage and will change in the future.

For now, to use that inside your package.json:

  "devDependencies": {
    "@holochain/tryorama": "git://github.com/holochain/tryorama#rsm",

Credit to @tats_sato for finding this.


Seeing as there is no way to memory debug whats happening inside the wasm.
we are reliant on debug outputs, forced panics and function returns to determine what the rust code is doing.
Many runtime error responses are also “unknown error”.

This makes working with complex zomes slow and often challenging work.
As far as I understand, the only serious tool we have for testing zomes is tryorama… ?

There a few things on my wishlist…
First would be to use a custom log function that wraps a macro which tryorama would pick up in INFO mode … this would speed up development because we wouldnt have to wade through a mass of unrelated debug statements from rust or tryorama

welcome comments and experience


ping @thedavidmeister

i believe this is related to how wasmer handles the errors we return (it immediately bails), and currently we’re probably a bit aggressive about aborting and winding back the wasm when we could be returning errors such as “failed to delete an element that we cannot get from the network” to be handled by wasm

in this case the host would be reporting something like “host function completed successfully with a failure to do X” so that wasmer continues executing but then the guest needs to handle that failure

this means the guest will need to be more explicit about handling these cases, so probably a bit more boilerplate, but overall i’m expecting this to be less work because the error handling becomes explicit rather than getting swallowed by wasmer somewhere

depends what you mean by ‘serious tool’ - you can also write rust unit tests for the wasm itself rust tests that drive the ribosome/conductor (e.g. core doesn’t use tryorama to test itself)

i’m currently looking at integrating the rust tracing crate more deeply with the HDK, e.g. including line numbers etc. tracing the most common issues (e.g. bytes that fail to deserialize), creating a tracing span for #[hdk_extern]

tracing supports filtering based on metadata associated with events/spans so i’m expecting that it will be possible to filter logs down to the specific extern and verbosity level that you need, at least from rust

for the tryorama side of things cc: @maackle maybe

Thanks @thedavidmeister and @maackle good work … look forward to updates

https://github.com/holochain/holochain/pull/624 here’s the PR that integrates tracing with the HDK

you can disable all logs from the holochain binary with RUST_LOG and filter to what you need out of wasm with WASM_LOG - as per rust tracing crate conventions


1 Like

this is merged, @nphias it should be possible to disable conductor logs with RUST_LOG and enable WASM_LOG (set to debug by default) and use the tracing crate inside wasm, as of latest develop

next i’ll change the error handling in host calls to return the error back to the wasm to be handled rather than short circuiting


https://github.com/holochain/holochain/pull/629 this is merged, @nphias the runtime errors should return to the guest now instead of short circuiting wasmer