@blackeggs@infosec.exchange An easy way to implement any data structure like this is to implement the memory itself semi-persistently. That is, you have a semi-persistent abstract data type which is called a memory. It implements read_uint16, write_uint32, copy_bytes, undo, redo, etc, and it keeps an undo/redo log of what it overwrites and at what offset so you can undo/redo it later.
@blackeggs@infosec.exchange You also want a snapshot method that essentially gives you an undo/redo boundary. That way the internal representation and granularity of the undo/redo log doesn't have to be 1:1 with individual update operations, which gives you more flexibility.
@pervognsen@mastodon.social Right, I think you mean like a begin_undo, end_undo. A grouping of memory operations contained in each undo history.
@blackeggs@infosec.exchange Yeah, you can do it that way but it's too error prone to have begin_undo since if you allow unlogged updates to happen it will desync any existing undo/redo log entries. So it's better to always log changes. Keep in mind this isn't for all memory in the system. Just for the backing memory of the arena (or whatever) you're using for that data structure you want to be semi-persistent.
@pervognsen@mastodon.social ahh ok, so there would just be a undo_snapshot function that creates like a bookmark since the last boundary point.
@blackeggs@infosec.exchange Correct. And remember what I said about the flexibility this opens up? You have to log the updates incrementally as they happen, but because you're not required to preserve the granularity except at bookmarks you can do things like coalesce or dedup changes since the last snapshot into an entirely different representation when someone takes a snapshot, if you'd like.
@blackeggs@infosec.exchange As a silly example, suppose there's a snapshot where all the logged changes were writes to the same byte location. The only thing you ultimately have to care about for the snapshot is the initial value of the overwritten byte from the last snapshot, so everything else can be tossed. It's more or less log compaction but you don't have to use the same representation for the most recent op log and the snapshot log, if that makes sense.
@pervognsen@mastodon.social that does makes sense and helps clarify things :)
Per Vognsen