More options for --keep-traces

[KristianBalaj]

I'd like to be able to disable all Aiken trace messages but keep just the user defined.

The tracing is done via the builtin.debug or the builtin fail where the tracing effect of these functions is enabled when the --keep-traces is passed to the compilation command, but it includes all the traces from the language and libs (stdlib, etc.), too.

[KtorZ]

There's actually no difference between user-defined traces and traces coming from the stdlib. The stdlib is user-defined! There are some traces defined directly by the compiler though but I wonder what the use case is here? It sounds like something that could be potentially quite confusing.

[KristianBalaj]

There's actually no difference between user-defined traces and traces coming from the stdlib.

Yeah I'm aware of this.

I wonder what the use case is here

We prefer to leave traces on for our on-chain code for debugging purposes. It's easier to troubleshoot and quickly respond to errors even on mainnet. Based on our experience, it's a good decision to use validators with traces on.

But the traces in Aiken are bloated - since they're meant just for developer experience purposes so it's understandable that they're verbose.
In comparison to PlutusTx which has it's errors coded with shortcuts - for reference: https://plutus.readthedocs.io/en/latest/troubleshooting.html#error-codes

This makes our validators compiled with --keep-traces quite large in size.

For the purposes mentioned above it would make most sense to us to leave just the user defined traces on and turn off the Aiken traces. And even maybe make this behaviour configurable per library.

[rvcas]

Hm this is a slightly strange position to hold. If you're debugging on Mainnet that's kinda not a good vibe. Generally it's a good idea to remove all traces when eventually going live. But we can think about a good solution for this.

[KristianBalaj]

If you're debugging on Mainnet that's kinda not a good vibe.

Of course not talking about on-chain debugging rather debugging of errors coming from specific user environments and inputs and so finding a lack of robustness in the offchain code or the offchain library.
That's the use-case where we've found it useful to have these traces even in production + other logs of user activity like the submitted transaction, etc. It helps to address such issues more quickly.

And in the end, it doesn't influence the on-chain too much having traces on-chain since reference scripts are a thing. So that's a good tradeoff - larger script size for easier interpretability.

[rvcas]

That's a good point. We'll see what we can do about this.

[MicroProofs]

To revisit this. How about Aiken has short url links for the traces instead of wordy long sentence traces. Then people could follow the url to get a good user experience on how to solve their trace. @rvcas

[waalge]

I am using traces instead of code comments relying on the fact that aiken makes it trivial to build without.
However, they are either all on or all off, so I wont be able to uses traces to debug on mainnet (validator with all traces is too big)

Any thoughts on having something akin to logging levels on traces? I cant think of a way of doing this that is worth the added complexity but it would be alt way to accommodate this. Something like: providing error codes and being able to filter on them.

Simply commenting and uncommenting is not so seemless. The formatter eagerly strips braces where the trace has only one sibling and uncommenting is then invalid syntax.

[KtorZ]

Kind of, we've been thinking about having possibly 3 level of traces:

• Verbose: Current behavior when --keep-traces is on.
• Concise: only line numbers of the trace are shown, instead of the trace itself. Possibly with a bit of instrumentation (e.g. if you simulate a transaction within your Aiken project, we could also have the compiler pull the trace from the source code for you and display it in the same way as the verbose).
• None: Current behavior when --keep-traces is off.

[waalge]

That's ... Probably much better than what I had in mind.

Use case: certain tx is failing. Validators have early branching. Include only traces on critical branch

[KristianBalaj]

I like this idea. It's essentialy encoding messages to short codes without any additional work for the developer.

[MicroProofs]

Now we will have more options soon #800