Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

soroban-cli inspect should generate human-readable output #136

Open
jonjove opened this issue Sep 16, 2022 · 5 comments
Open

soroban-cli inspect should generate human-readable output #136

jonjove opened this issue Sep 16, 2022 · 5 comments

Comments

@jonjove
Copy link
Contributor

jonjove commented Sep 16, 2022

What problem does your feature solve?

inspect doesn't render names as strings, doesn't give pretty (possibly rust-like?) representations of structs and unions, etc.

What would you like to see?

Easy to read output.

What alternatives are there?

TODO

@jonjove
Copy link
Contributor Author

jonjove commented Sep 16, 2022

Those issues are only a partial solution. It handles the names as strings part but not the pretty representations of structs and unions.

For concreteness, soroban-cli inspect --wasm <token contract wasm> currently outputs (snippet)

 • Union: ScSpecUdtUnionV0 { lib: VecM([]), name: VecM([68, 97, 116, 97, 75, 101, 121]), cases: VecM([ScSpecUdtUnionCaseV0 { name: VecM([65, 108, 108, 111, 119, 97, 110, 99, 101]), type_: Some(Udt(ScSpecTypeUdt { name: VecM([65, 108, 108, 111, 119, 97, 110, 99, 101, 68, 97, 116, 97, 75, 101, 121]) })) }, ScSpecUdtUnionCaseV0 { name: VecM([66, 97, 108, 97, 110, 99, 101]), type_: Some(Udt(ScSpecTypeUdt { name: VecM([73, 100, 101, 110, 116, 105, 102, 105, 101, 114]) })) }, ScSpecUdtUnionCaseV0 { name: VecM([78, 111, 110, 99, 101]), type_: Some(Udt(ScSpecTypeUdt { name: VecM([73, 100, 101, 110, 116, 105, 102, 105, 101, 114]) })) }, ScSpecUdtUnionCaseV0 { name: VecM([83, 116, 97, 116, 101]), type_: Some(Udt(ScSpecTypeUdt { name: VecM([73, 100, 101, 110, 116, 105, 102, 105, 101, 114]) })) }, ScSpecUdtUnionCaseV0 { name: VecM([65, 100, 109, 105, 110]), type_: None }, ScSpecUdtUnionCaseV0 { name: VecM([68, 101, 99, 105, 109, 97, 108, 115]), type_: None }, ScSpecUdtUnionCaseV0 { name: VecM([78, 97, 109, 101]), type_: None }, ScSpecUdtUnionCaseV0 { name: VecM([83, 121, 109, 98, 111, 108]), type_: None }]) }

which is not pleasant. Even if the names were rendered correctly, the types would still be quite unpleasant. From my perspective, the desirable output would be something like (snippet)

 • Union: DataKey { Allowance(AllowanceDataKey), Balance(Identifier), Nonce(Identifier), State(Identifier), Admin, Decimals, Name, Symbol }

@leighmcculloch
Copy link
Member

Maybe for the use case you're looking for the soroban-cli gen --type rust would be more appropriate? It generates a Rust version of the contract, and so all the types are Rust, etc.

The inspect command is more useful for debugging, but maybe it is too low level and the low level output it outputs right now should be an option.

@jonjove
Copy link
Contributor Author

jonjove commented Sep 16, 2022

Ah yes gen is much better, that's basically exactly what I was looking for. I'm not personally sure what the use case for inspect is as currently implemented (or even with nicely formatted names). It's just so difficult to read that I can't really imagine a situation where a user would rather that over basically any other format.

@leighmcculloch
Copy link
Member

leighmcculloch commented Sep 16, 2022

I'm not personally sure what the use case for inspect is

It was intended for debugging the raw contents of the WASM, and not the interpreted contents. It shows you things like the environment version, and the raw contract spec as XDR. A last line of defense against everything is broken and you want to see what's in the file. It used to also print the raw functions available according to the WASM but I took it out temporarily but would like to add that back, along with a list of all host functions it is dependent on.

It sounds like the command could do with two modes, one for these raw details and one that is by default the user friendly view, where the user friendly view has to interpret the contents and the raw does not. Or these could be two separate commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants