Would it be nice if Observable detected endless loops and highlighted them as errors?
This loop has no chance to be completed.
But because it is constantly spinning, it gives the impression that Observable hangs and/or makes a heavy load on browser.
1 Like
These aren’t actually infinite loops. The cell isn’t constantly running, it is actually waiting for the value of some_markdown. The viewof operator expects it’s argument to have a .value property, which turns into the value of the cell used elsewhere. Since md doesn’t assign a value property, Observable waits for it to appear. So if anything, the first cell in your notebook should be the highlighted one, not the two you circled.
True infinite loops are possible, but extremely tricky to do much about. If the worker is running an infinite loop, it won’t stop to receive messages to stop running that infinite loop. We mostly rely on browsers’ “slow script” warnings for this.
Perhaps if a cell takes longer than some threshold it could be flagged as slow, but some cells intentionally take a very long time to resolve, like cells that wait for user input. It would be hard to tune right.
1 Like
There is no way for user to know that the reason for the hang is that viewof expects .value, and there is no way for the user to know that the line that calls some_markdown expects .value.
I can ask questions in the forum once in a while, but most user bounce. So the more they can learn from error messages, the higher will be their conversion rate.
- Learn from errors
- Know what to do from errors
- Automate the fixes, provide even more descriptive errors
In ideal (programming) environment, each error is a clear choice between clear actions.
@abitrolly There is no error here, this particular behavior is by design. Cells that depend on a viewof cell don’t immediately resolve if the view’s initial value is undefined (viewof uses Generators.input() from Observable’s Standard Library under the hood).
It’s the same as having a cell return a promise that never resolves:
new Promise(()=>{})
I do however see that the docs don’t yet mention the behavior.
@abitrolly
I can see that this behavior is not totally obvious. I would love to learn a little bit more about what you were trying to do with that first cell where you used the viewof, Since that is really meant to be used with an input that returns the value as Michael described.
@Cobus thanks for the confirmation of the non-intuitive behavior. I was trying to debug the error RuntimeError: e.addEventListener is not a function.
The thing is, I want zipStream cell to show the message if there is no input, and if there is input then show the value of fetch. My mistake was using viewof. I probably wanted to show some other info instead of zipStream = Blob {} when the file is fetched.
The problem is - there is no way to understand what is going on by looking at the errors. One need a lot of prior knowledge about to debug and resolve such errors. To understand that this specific problem is in misuse of viewof in a certain condition.