How to debug the right way

Community Help
1

Hi @all,

I hope you all had a nice Christmas and also took some time off to relax. I have some free time and want to learn new things. Doing so, i write a lot of buggy code in Observable and i often come to a situation where i want to get some (dynamic) state inside a block.

For example

someBlock = {
    while (...) {
         const internalState = {};
         const res = doThing(internalState);
         // i want to check res
    }
}

I tend to use console.log in those cases but it forces me to open the dev tools and this feels “not right”. So i was wondering if there is an intended way to debug code in this situation that is easier to use.
I am not entirely sure if those situations could always be resolved with better “code planning”.

I hope i am not overseeing something totally obvious and could articulate my problem in a somewhat understandable way…

P.S. to give a more concrete example

{
    // i want to check vec
    const geometry = new THREE.ParametricBufferGeometry((u, v, vec) => { }, 20, 20);
    ....
}
1 Like
2

I’ve only ever used a combination of console.log and debugger statements. About debugger: if you have your browser’s dev tools open when a debugger statement is evaluated, the Javascript will pause and you can explore the variables / state in your dev tools.

4 Likes
3

Adding to what @bgchen wrote, you can wrap debugger; statements in conditions (e.g. to only execute them if a checkbox is checked). Other useful tools are:

  • logpoints, which are managed like breakpoints, but instead of halting they just dump a value in the logpoint scope to the console
  • console.assert(), which is like a conditional console.error() and can e.g. be used for sanity checks in calculations (e.g. console.assert(!isNaN(myvalue), 'got a valid number').

If you want something more integrated, my documentation helper signature has some limited support for tests (a few more examples of its application can be found in my work-in-progress Toolbox notebook.

If you want to monitor values in another cell, there are many ways to go about that:

  • use mutable to update another cell
  • use DOM events and have a cell listen to them
  • set your debug value as the value of a viewof cell and trigger an input event
  • currying a function to perform some logging action before passing parameters on to the original function
  • …

While console.log may not be ideal, it is often appropriate given the debugging limitations of Observable’s generated code. I would also argue that your notebook is the “presentation layer”, and using the dev tools to spot and analyze errors is exactly right. :slight_smile:

5 Likes
4

Thanks for your nice and detailed answer, especially your argument about the notebook as the presentation layer might be right. Never the less I think it might be potentially awesome to have some sort of interaction between the “dev layer” and the “presentation layer”.
This is by no means a feature request but more an inspiration. For example in Matlab there is the concept of a workspace, where you can see the current state.

workspace_browser

From what i understand this might be similar to how the debugger statement works. But having it as a separate tool similar to history (which is still awesome by the way) is maybe worth thinking about.

5

I’ve hacked together a very basic draft of such a tool:

6 Likes
6

A cute on-screen console with n watches!

In stead of inserting all those one-line debugging cells: combine them all in one view. Looks like a simple yet powerful solution for medium-sized debugging problems. Thank you @mootari !

Btw: I totally agree with @mootari that the dev tools are legitimate (and often necessary) helpers. I can only guess what does not “feel right” for @tau, and certainly does not feel good for myself:

  1. opening dev tools involves a considerable delay and therefore interrupts my workflow (unless they are open all the time, which they rarely are in my case)

  2. opening dev tools drastically reduces ‘width’ for the HTML page and triggers a new layout. Not only does the new layout deviate from my intended or “production” layout. It also drags my mental focus away from the Notebook, and again interrupts my workflow on the mental level. Unless I am working with a huge screen where I can configure dev tools to open as a separate window.

1 Like