Runkit stops running code cells after ~1 hour

First, I want to say thanks for a fantastic product! I love messing around with Runkit, and using it as a way to share simple ideas in code with people who don’t have a coding environment set up themselves.

I have one, major, enduring gripe though. If I am working on a notebook for longer than about one hour, the notebook will often just die on me. I can continue to edit and save my code, but new code cells will not print output, and old code cells’ output will not reflect changes.

This precludes me trying to schedule a workshop or demonstration based on Runkit. :frowning:

The most recent notebook I encountered that with is here: https://runkit.com/ajhyndman/count-wins-fe-heroes/0.1.0

At the time of this post, I still cannot get my last four code cells to render any output. I am also trying to import this notebook in another notebook, and my require call seems to be resolving to an empty object.

I’d be happy to listen to workarounds as well, but this has been a consistent, recurring issue for me.

Hi there, so the reason your notebook stops giving outputs is because there’s actually a logic error in your function… the while loop appears to never terminate and thus it’s running forever. I’ve adjusted it here so the loop eventually terminates:

I think that same fix will also fix the problem with requiring the notebook. But please let me know if that doesn’t work.

Wow. That’s totally on me!

Maybe Runkit is fine after all, and I’m just writing shitty code! :smiley:

I did find lack of any output a bit confusing. Maybe there’s a way to make it clearer that a code cell has timed out, or is still running? Thanks for the prompt assistance!

Alright, I am still having some issues with requiring the notebook. I’ve tried every version of module.exports = { ... } that I can think of. Does Runkit have a special syntax for this? Is requiring notebook still supported? It’s kind of hard to look that information up.


So, if I remove the @0.7.6 from the two libraries I get much farther. However, it still times out because the library itself spends a lot of time before setting any exports. A good strategy here is to use if (require.main === module) around the calculation you do in the required notebook. This will make it so that they are only done when you are running the notebook itself, and not when it is being required. That way, when you are in the notebook, you get to test it, but when you require it, it is very fast. Here is an example:

Thanks for the tip! That should get me going for now.

I do feel like there’s a pattern here of not visualizing timeouts. If I knew that performance was an issue, I would be able to self-diagnose both of these issues, for instance.