Decouple clock number from size of history (Max history depth)

[Freddo3000]

Having clock number tied to history causes issues on higher clock numbers, as it is effectively a memory leak. It would be better to keep it separate, and add a limit to how large the history size can grow before it starts discarding the oldest records. I also suggest that instead of clock being stored in GuiData it is instead fetched when needed from the simulator.

[perlindgren]

The reason to have clock in GuiData is that it provides a lens, so when changed components like the ProbeEdit knows that something has happened.

Regarding memory leak, I don't quite follow.

[Freddo3000]

Regarding memory leak, I don't quite follow.

I mean that keeping an unlimited sized history might not be optimal, as it might cause issues if you for example leave the clock running in the background and forget about it, as it will endlessly grow.

[perlindgren]

Indeed, the simulator holds the history (as a Vec<...), it would be perfectly possible to limit the size and have it dropping oldest element, on enqueing a new. Maybe a double linked version would be better with cheap operations on both head and tail.

[perlindgren]

Components (and GUI elements) that holds internal state etc., is responsible for their own history management, essentially triggered by clock, un_clock and perhaps also reset (currently not implemented though).