Add a gap to the store, extending the run in progress if this one continues it. Gaps arrive in order, so a run ends as soon as one arrives that does not continue it.

Where that address lies in the simulation that answered - the key the cache holds it under.

The location a memory is reading at `step`, from whichever simulator is running.

The cycle at which a memory's address input says what it is reading, for a location shown at `step`. A write lands one clock after the address that caused it, and a synchronous read presents its data a clock late; an asynchronous one does not. RamView.readAndWritten draws the same distinction on the other side of the wire.

A memory's address input, in the instance it is in - the wave that says what it is reading at each cycle. A fact about the elaborated instance, so it comes from `PortView`, like every other driver the wave simulator uses. Fetched with the waveforms being drawn rather than asked for on demand: both the things that want it - the tooltip below, written into the DOM by a mouse handler, and the read marker on a ROM's rows, drawn in a render - happen where nothing can wait. A WAVE and not a driver index, because a fetch asks for waves: naming a port is what lets the simulator holding the data find it, and the index alone no longer names anything.

Change the tooltip text and position.

Check if a wave is hatched at a given cycle. This is done by checking if the cycle is within any of the gaps in a mutable store, which is updated as gaps are added.

SVG group element for tooltip. The props of the tooltip, as well as its text, are set in the function changeToolTip. Initila props make it invisible.

Store the run still in progress, if there is one. There is nothing to merge with: a run is stored only when the gap that ended it started somewhere else, so the run in progress never touches the one before it. The branch that tried to merge them could not fire, and would have overwritten the stored run's start if it had.

The comment written in a .ram file against the location a ROM is reading at a given simulation step, if the ROM has any comments and this wave is its data output. The location read is the address input one step earlier for a synchronous ROM and at the same step for an asynchronous one, which is the distinction RamView.readAndWritten also makes. The address comes from `WaveData`, which answers from whichever simulator is running - the local arrays where the renderer is simulating, and the window fetched from the sidecar where it is not. It used to be read straight out of the renderer's own FastSimulation, which in .NET mode is built for its structure and never run: every address would have been an unrun array's zero, so the comment against location zero was shown on every hover, confidently. That was guarded by refusing to answer at all, which is why these comments disappeared in that mode. None where the address is not among the samples held - a synchronous ROM's address is one CYCLE back, and at a zoom where a column is several cycles wide that is not a sample that was fetched. No comment is better than the wrong one.

Text for the tooltip shown when hovering a waveform at a given cycle, or "" for no tooltip. A value is given when the wave is too narrow there to have its number printed on it - the cached "gap" data says when that is - and a ROM's data output also gives the comment written against the location being read, so that both appear when the number is hidden as well. The wave is passed in rather than counted off SelectedWaves by row number. The rows drawn are the selected waves that WaveDetails still HOLDS - see WaveSimStyle.selectedWaves, which the three columns are all built from - so counting rows off SelectedWaves itself answered for a different row wherever the two differ, and indexed WaveDetails with a key it might not have. Everything is asked of the waveform AS DRAWN - the gaps in it, the samples it was drawn from, and the cycle they are of. What is under the pointer is a column of a picture, and the picture may be a window behind the controls while its data is still on its way; the tooltip describes what is there rather than what has been asked for. `sample` is therefore an index into that picture, counted from its left edge, and NOT a clock cycle. It used to be given the absolute display cycle and to test it against gaps recorded from the window's left edge, so a viewer scrolled anywhere but cycle 0 asked about the wrong column.

A gap in the wave simulator, represented by a start cycle and a length. the only gaps that are stored are relevant are those that correspond to hatched parts of the waveform in which the wave value is not printed. A store with room for `maxGaps` runs and no run in progress. GapStart and GapEnd are -1 for "nothing pending", not 0. Zero was indistinguishable from a run starting at cycle 0, so a view whose first hatched gap was anywhere else opened by storing a zero-length run - one slot spent on nothing. With the store sized for the most runs a view can hold, that one extra entry was one past the end: harmless in JavaScript, where writing past an array extends it, and an exception anywhere else.

Whether a memory's contents can change as a simulation runs. A ROM's cannot: what it holds is part of its type. Only the location it is READING moves, which is why its rows are worth fetching once and marking again as the cursor moves, while a RAM's have to be fetched afresh for every cycle they are shown at.

The memory this wave is the data output of, when it has comments worth showing, together with the driver of the address it reads. Which memory it is and what its .ram file said are facts about the component as DRAWN, so they come from the design. Where its address lies is a fact about the elaborated instance, so it comes from `PortView` - like every other width and driver the wave simulator uses. Returned as a pair because both callers want both: the tooltip below, to write the comment, and WaveSimTop.missingForWaves, to fetch the address wave along with the ones being drawn. Fetched with them rather than on hover because a tooltip is written into the DOM by a mouse handler, which cannot wait for anything - so the address has to be there before the pointer arrives.