-
Notifications
You must be signed in to change notification settings - Fork 63
Control stack trace depth when showing failing code segments #161
Comments
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.
Would this work for you? |
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? |
You'll need to pass this to sbt when you start up ( |
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? : ) |
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 |
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. |
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.
The text was updated successfully, but these errors were encountered: