Skip to content
This repository has been archived by the owner on Apr 13, 2021. It is now read-only.

Control stack trace depth when showing failing code segments #161

Open
imarios opened this issue May 13, 2017 · 6 comments
Open

Control stack trace depth when showing failing code segments #161

imarios opened this issue May 13, 2017 · 6 comments

Comments

@imarios
Copy link
Contributor

imarios commented May 13, 2017

Often, you want to show what happens when you make a mistake in the code and you see a runtime error (say if you are making an Apache Spark tutorial). Currently the stack traces can be arbitrary long, which take a lot of prime real estate in the tutorial. It would be amazing if some control is given to the depth of a stack trace using some form of sbt configuration parameter.

@tpolecat
Copy link
Owner

There is not an obvious way to do this within tut because the stracktrace is printed by the REPL as a side-effect and we don't know it has happened until we get the result back saying there was a failure. However you can control this with a JVM option.

-XX:MaxJavaStackTraceDepth=10

Would this work for you?

@imarios
Copy link
Contributor Author

imarios commented May 13, 2017

Thank you! Let me play around with this setting. Do you think this is something we can pass to IMain? does tut gets the stack trace directly from the interpreter?

@tpolecat
Copy link
Owner

You'll need to pass this to sbt when you start up (-J-XX:... if you're using sbt-extras) because it all runs in-process and this is a JVM option. It's possible that you could sneak it into a new JVM if we forked tut into a new JVM but it doesn't know how to do that right now.

@imarios
Copy link
Contributor Author

imarios commented May 13, 2017

Hmm.. true, the jvm settings do not take affect if you are already re-using the jvm you are on. Did anyone ever tried to have tut tasks run on a forked jvm? any skeletons I may encounter if I choose to take this path? : )

@tpolecat
Copy link
Owner

I don't know how hard this would be, I haven't looked into it. Things in sbt vary from trivial to near-impossible seemingly at random so it's hard to predict. Feel free to take a look. The beef is likely to be in or near the ScalaRun used by TutPlugin.

@imarios
Copy link
Contributor Author

imarios commented May 13, 2017

Yup, that fact that the tut-plugin code already abstracts over the ScalaRun trait might make this easier. Currently tut tasks run over the default runner (which extends the ScalaRun trait). The ForkRun also extends ScalaRun, so just swapping a new runner conditioning on if(fork) might just do it. Let me give this a try.

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

No branches or pull requests

2 participants