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

optimize invoke output #316

Merged
merged 7 commits into from
Nov 18, 2023

Conversation

Ashuaidehao
Copy link
Collaborator

Try to convert ByteString to string when invoke contract with "--result".
Partial solution of #274.

Copy link
Member

@cschuchardt88 cschuchardt88 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should be checking the manifest for the return type to see if it is string

@Ashuaidehao
Copy link
Collaborator Author

Hardly check manifest outside of the vm :( .

{
try
{
text = Encoding.UTF8.GetString(data);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be easier to use Strict UTF-8?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will get very low perfomance to catch the exception when using random data with Strict UTF-8. try-catch here is use for robust, and I don't expect it runs into catch case.

byte[] reencodedBytes = Encoding.UTF8.GetBytes(text);
for (int i = 0; i < data.Length; i++)
{
if (data[i] != reencodedBytes[i])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could check for char.IsAscii()

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry I don't get it. If the data is encoded utf-8 string, checking IsAscii is not enough.

Copy link
Member

@cschuchardt88 cschuchardt88 Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You allow strings to be displayed that are not human readable?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If utf-8 convert successfully, it is already readable without extra checking.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok thought you were using ASCII for some reason... 😂

await WriteLineAsync(Neo.Helper.ToHexString(byteString.GetSpan())).ConfigureAwait(false);
if (byteString.GetSpan().TryGetUtf8String(out var text))
{
await WriteLineAsync($"{Neo.Helper.ToHexString(byteString.GetSpan())}({text})").ConfigureAwait(false);
Copy link
Member

@cschuchardt88 cschuchardt88 Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think text 1st then hex. Or put on different lines when printing.

Example: Return: "Hello World" (Hex-Format: "48656c6c6f20576f726c64")

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not a accurate convert, some random data could be converted to string. So I prefer show its text as a possible value after the certain value(HexString).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but you are showing string and hex-string. Think it neater for it to look like this "Hello World" (Hex-Format: "48656c6c6f20576f726c64") and more understandable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have the StackItem, why not use StackItem.GetString()? that will fix this problem.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

StackItem.GetString() will throw exception if it is not a valid string.

@Jim8y
Copy link
Contributor

Jim8y commented Nov 14, 2023

Merge?

@cschuchardt88
Copy link
Member

cschuchardt88 commented Nov 14, 2023

@Liaojinghui i still think that we should be checking the manifest for return type string or be using StackItem.GetString(). The current way is dirty and inefficient.

@lock9
Copy link
Contributor

lock9 commented Nov 15, 2023

Hello!

I'm a bit worried about this PR 🤔 It doesn't look like I expected it to be 🤔 🤔 🤔

Can we do a post-processing step to parse the JSON and use the manifest to ensure String compatibility? @Ashuaidehao

@Ashuaidehao
Copy link
Collaborator Author

Hello!

I'm a bit worried about this PR 🤔 It doesn't look like I expected it to be 🤔 🤔 🤔

Can we do a post-processing step to parse the JSON and use the manifest to ensure String compatibility? @Ashuaidehao

Yes, but the best way to implement it requires neo-vm expose more infomations, it may cost more time to discuss and couldn't process custom scripts without contract invoking. This PR is just a quick way show possible value to developers, and the developers should know what the return value is.

@cschuchardt88
Copy link
Member

the developers should know what the return value is.

What if result comes from an oracle?

@Ashuaidehao
Copy link
Collaborator Author

the developers should know what the return value is.

What if result comes from an oracle?

Could oracle results show here? I'm not sure if I miss some scenarios.

@cschuchardt88
Copy link
Member

I dont remember, but i can't see why not.

@Jim8y Jim8y merged commit 07a18b3 into neo-project:master Nov 18, 2023
2 checks passed
@Ashuaidehao Ashuaidehao deleted the optimize-invoke-result-string branch November 26, 2023 13:54
@cschuchardt88 cschuchardt88 mentioned this pull request Dec 3, 2023
22 tasks
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

Successfully merging this pull request may close these issues.

4 participants