mdoc
mdoc copied to clipboard
Stream output from worksheets
If an evaluation is taking longer time or even not ending it's not possible currently to get the output that is being printed. For example this evaluation will never finish:
def isCloseEnough(a: Double, b : Double) = Math.abs(b - a) <= 0.05
def fixedPoint(f: Double => Double)(firstGuess: Double): Double =
def iterate(guess: Double): Double =
val next = f(guess)
println(next)
if isCloseEnough(guess, next) then next
else iterate(next)
iterate(firstGuess)
fixedPoint(a => a + 1)(1000)
user might want to print the current numbers to output to see what's going on.
Possible solutions:
- add an additional reporter to interfaces that can send current output to the client
- allow an option (have it as default) of printing the output to the ConsoleReporter, which already is in the interfaces
I was thinking of trying out to implement the first one and seeing how it goes with it.
Anyone has other ideas?
CC @odersky
I think println just has to work, unconditionally. It should show up in the output without the user having to hunt for where it is. Anything else would be really hard for me to justify in the online courses.
- Martin
On Thu, Aug 27, 2020 at 8:11 PM Tomasz Godzik [email protected] wrote:
If an evaluation is taking longer time or even not ending it's not possible currently to get the output that is being printed. For example this evaluation will never finish:
def isCloseEnough(a: Double, b : Double) = Math.abs(b - a) <= 0.05 def fixedPoint(f: Double => Double)(firstGuess: Double): Double = def iterate(guess: Double): Double = val next = f(guess) println(next) if isCloseEnough(guess, next) then next else iterate(next) iterate(firstGuess) fixedPoint(a => a + 1)(1000)user might want to print the current numbers to output to see what's going on.
Possible solutions:
- add an additional reporter to interfaces that can send current output to the client
- allow an option (have it as default) of printing the output to the ConsoleReporter, which already is in the interfaces
I was thinking of trying out to implement the first one and seeing how it goes with it.
Anyone has other ideas?
CC @odersky https://github.com/odersky
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scalameta/mdoc/issues/380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGCKVUCLKQJTYSLGDGGDF3SC2OS5ANCNFSM4QNIUCKA .
--
Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland
The reasoning why stdout is current only visible via mouse hover is that you normally don’t need println in worksheets, toplevel values are displayed as decorations by default. It’s certainly possible to include stdout in the decorations but how should we format multiline stdout? Should we remove the formatting of toplevel values?
As for streaming, decorations are published for the entire document (like diagnostics) so we would get quadratic performance if we stream every stdout event. We can avoid this problem by flushing once per second or so. Would that satisfy the UX requirements? I estimate it’s not a large effort to implement.
I think flushing every second or so would be acceptable. But I think at least the first 5 or so lines should be in the output, to make sure it is seen. One can stop after that and indicate that full message is available in hover.
Another problem:
val xs = List(1, 2, 3) xs.mkString("\n")
gives
: String = """123"""
where it should give
: String = """1 2 3"""
So, it seems to me the multi-line output problem has to be solved one way or another.
On Fri, Aug 28, 2020 at 6:57 AM Ólafur Páll Geirsson < [email protected]> wrote:
The reasoning why stdout is current only visible via mouse hover is that you normally don’t need println in worksheets, toplevel values are displayed as decorations by default. It’s certainly possible to include stdout in the decorations but how should we format multiline stdout? Should we remove the formatting of toplevel values?
As for streaming, decorations are published for the entire document (like diagnostics) so we would get quadratic performance if we stream every stdout event. We can avoid this problem by flushing once per second or so. Would that satisfy the UX requirements? I estimate it’s not a large effort to implement.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scalameta/mdoc/issues/380#issuecomment-682324962, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGCKVXBADZ52E7PHXKBEQ3SC42NNANCNFSM4QNIUCKA .
--
Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland
In fact, playing more with it it seems more of the string formatting is off. If I do a mkString(" ") with two spaces it will still only print one space. That should be fixed as well. we need to see the string exactly as it was printed.
On Fri, Aug 28, 2020 at 8:49 AM martin odersky [email protected] wrote:
I think flushing every second or so would be acceptable. But I think at least the first 5 or so lines should be in the output, to make sure it is seen. One can stop after that and indicate that full message is available in hover.
Another problem:
val xs = List(1, 2, 3) xs.mkString("\n")
gives
: String = """123"""
where it should give
: String = """1 2 3"""
So, it seems to me the multi-line output problem has to be solved one way or another.
On Fri, Aug 28, 2020 at 6:57 AM Ólafur Páll Geirsson < [email protected]> wrote:
The reasoning why stdout is current only visible via mouse hover is that you normally don’t need println in worksheets, toplevel values are displayed as decorations by default. It’s certainly possible to include stdout in the decorations but how should we format multiline stdout? Should we remove the formatting of toplevel values?
As for streaming, decorations are published for the entire document (like diagnostics) so we would get quadratic performance if we stream every stdout event. We can avoid this problem by flushing once per second or so. Would that satisfy the UX requirements? I estimate it’s not a large effort to implement.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scalameta/mdoc/issues/380#issuecomment-682324962, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGCKVXBADZ52E7PHXKBEQ3SC42NNANCNFSM4QNIUCKA .
--
Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland
--
Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland
One more problem: If I convert the problematic example to a full program and press run, I get a non-terminating sequence of output in debug console. But it seems there's no way to stop that? Except waiting for a timeout? That's also not practical for teaching. If we don't have a solution I don't know what to do anymore.
For background, here's the exposition, which worked really well in the last course:
- I explain what fixedpoints are.
- I explain that square root is the solution to the equation x = y * y or y = x / y which suggests a fixpoint for the function y => x / y.
- I invite people to try it out and observe nontermination.
- I then introduce average damping.
It's the classical piece to show why functional programming matters, and a great demonstration of our tools.
On Fri, Aug 28, 2020 at 8:51 AM martin odersky [email protected] wrote:
In fact, playing more with it it seems more of the string formatting is off. If I do a mkString(" ") with two spaces it will still only print one space. That should be fixed as well. we need to see the string exactly as it was printed.
On Fri, Aug 28, 2020 at 8:49 AM martin odersky [email protected] wrote:
I think flushing every second or so would be acceptable. But I think at least the first 5 or so lines should be in the output, to make sure it is seen. One can stop after that and indicate that full message is available in hover.
Another problem:
val xs = List(1, 2, 3) xs.mkString("\n")
gives
: String = """123"""
where it should give
: String = """1 2 3"""
So, it seems to me the multi-line output problem has to be solved one way or another.
On Fri, Aug 28, 2020 at 6:57 AM Ólafur Páll Geirsson < [email protected]> wrote:
The reasoning why stdout is current only visible via mouse hover is that you normally don’t need println in worksheets, toplevel values are displayed as decorations by default. It’s certainly possible to include stdout in the decorations but how should we format multiline stdout? Should we remove the formatting of toplevel values?
As for streaming, decorations are published for the entire document (like diagnostics) so we would get quadratic performance if we stream every stdout event. We can avoid this problem by flushing once per second or so. Would that satisfy the UX requirements? I estimate it’s not a large effort to implement.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scalameta/mdoc/issues/380#issuecomment-682324962, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGCKVXBADZ52E7PHXKBEQ3SC42NNANCNFSM4QNIUCKA .
--
Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland
--
Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland
--
Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland
One more problem: If I convert the problematic example to a full program and press run, I get a non-terminating sequence of output in debug console. But it seems there's no way to stop that? Except waiting for a timeout?

You should be able to just click on the stop button. It's not perfect in case of too much output, since it's trying to send all of it first, which we might be able to improve (although it might depend on the DAP protocol limitations), but seems to work most of the time.
Another problem: val xs = List(1, 2, 3) xs.mkString("\n")
This one seems to be a bug, I will take a look at it. Might be an issue with white spaces altogether.