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

[UX] Improve TensorIR jupyter misuse error message improvement suggestions #9551

Closed
tqchen opened this issue Nov 23, 2021 · 6 comments · Fixed by #9559
Closed

[UX] Improve TensorIR jupyter misuse error message improvement suggestions #9551

tqchen opened this issue Nov 23, 2021 · 6 comments · Fixed by #9559

Comments

@tqchen
Copy link
Member

tqchen commented Nov 23, 2021

Some lessons when trying out TensorIR on a jupyter session due to mis-use

  • When passing different types(list of loops) to the split API, type checking error message is not as clear, consider do checking and raise error on python side.

https://gist.github.com/tqchen/01915c90334dbc2699971afe40dd2996

@tqchen tqchen changed the title [UX] TensorIR jupyter error message misuse [UX] Improve TensorIR jupyter misuse error message improvement suggestions Nov 23, 2021
@junrushao
Copy link
Member

UX issue should be treated as a bug

@junrushao
Copy link
Member

The second issue is easier to fix: rewrite the error message.

The first issue is more profound: it comes from the type checking in packed function interface. One workaround is to check the input types on python side for each API. However I don't know better any general approaches to do so. On the other hand, if get_loops returns a list containing only one element, we can sugar it out; not sure if it's good design though because it sacrifices consistency

@junrushao
Copy link
Member

Is it possible to turn off the stacktrace? It doesn't look useful in jupyter

@tqchen
Copy link
Member Author

tqchen commented Nov 23, 2021

Let us check on the python side for the first one

@tqchen
Copy link
Member Author

tqchen commented Nov 23, 2021

Updated note on the c++ stacktrace side. The main annoying part are the expanded macro dispatchers in the FFI boundary that does not provide additional information.

So one solution is to update the trace normalizer to simplify and trim some of the less informative traces(e.g. unpackcall_dispatcher) but keep the rest of the useful traces

@junrushao
Copy link
Member

@tqchen The dispatcher can be completely avoided by using other metaprogramming tricks

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

Successfully merging a pull request may close this issue.

2 participants