Add the pipeline explorer and the prediction gate

[tamnd]

Closes the last two rows of #14.

The pipeline explorer

Six panes for one box of Python, all updating together: the token stream, the tree, the symbol table, the instructions code generation produced, the same instructions after the optimizer, and the finished code object.

They are on screen together because the point of the pipeline is that each stage throws away something the one before it had, and that is very hard to get across one paragraph at a time. A reader who has just finished the paragraph about the parser has forgotten what the tokens looked like. With six panes you add a comment to the end of the line and watch it sit in the tokens and be gone by the tree, or leave 6 * 7 alone and watch a BINARY_OP come out of code generation and be a plain LOAD_SMALL_INT 42 by the time there is a code object.

Code generation and the optimizer need _testinternalcapi. On a build without it those two panes say so and the other four still work, since a widget that shows nothing because one hook is missing teaches nobody anything about the four stages that would have run fine. There is a test that monkeypatches compiler.stages into raising Unavailable and checks the other four still draw.

Output is cut at forty lines per pane and the cut is counted rather than hidden.

The prediction gate

A question, some options, and the answer behind a gate.

Option will not be built without a why, including on the right answer. A wrong option is only worth offering if somebody could plausibly pick it, and if somebody could plausibly pick it then the reason it is wrong is worth teaching. Revealing shows every option's explanation, not only the one that was picked and not only the right one, so a reader who guessed correctly still finds out why the option they nearly picked was wrong.

The choice is written to the reader's own browser with localStorage and goes nowhere else. Nothing is scored and nothing is uploaded. A reader who thinks a wrong answer is being logged stops guessing and starts reading ahead, and guessing is the whole mechanism. The storage exists because notebooks get re-run and being asked six questions you have already answered is a good way to stop answering them.

The static rendering gates too, with <details> and <summary>: no JavaScript, keyboard reachable, and it works in a notebook rendered on GitHub. The options are a numbered list rather than disabled buttons, because a disabled button says the thing it does is unavailable and here the thing is just being done in the reader's head.

The shared front end

Three widgets meant three copies of paint, wire and put the caret back, so that moved to static/_common.js, which Widget.esm concatenates onto each widget module. Concatenation rather than an import: an import is a second network request from inside a notebook output cell, which works in Jupyter and does not reliably work everywhere else a lesson gets rendered.

Focus restoration is generic. HANDLES = ["role", "flag", "option"] is the list of data attributes that mark something a reader can put the keyboard on, so _common.js can find the same control again in markup it has never seen. Without it a source box sends you to the end of the line a quarter of a second after you stop typing.

Two smaller things

strings.text now fills in plural endings from the count value, so a template can write {count} scope{s} and get "1 scope" and "2 scopes". "1 scopes" was on screen in the first lesson, and that is the kind of thing a reader notices and then stops trusting.

The code object pane prints arg when argrepr is empty. LOAD_SMALL_INT keeps 42 in arg with an empty argrepr, so printing only argrepr dropped the one number the constant folding demonstration is about.

Checks

just check is green. The widget tests are 138 now, and the live path was run under --extra live: typing into the pipeline redraws all six panes, and picking an option on the gate reveals the explanations and the verdict.