You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I real and properly working undo function would be the greatest feature possible, I think. I guess that it's a bit difficult to pull it off in a somewhat memory efficient way due to all the side-effects every action can trigger.
Right, but memory isn't a scarce resource on modern workstation. And it would be hard to beat modern web browsers anyway (running top, I see 11 chromium processes, each with ~2GB VIRT size).
So yeah, there definitely no need to be shy to make users' life easier using the memory they have (just leave them in the control of that memory). And initial implementation can be as dumb as just making copies of all data structures (there're 2 - address space flags, one byte for each declared address space byte and address properties, more sparse, but also more weight per entry) before making an interactive change operation.
The concern here would be not memory usage, but speed of copying, I filed #37 in that regard. It should still be good for a typical under-1MB "embedded" project. And if larger projects will show issues, we can think about that later (the ideas are there - e.g. for flag space implement copy-on-write arrays, which would store only changed "pages", and props are fine-grained already, so only changes can be stored).
So, the idea is that user would be able to control levels of undo stored, and that will control amount of memory taken.
The text was updated successfully, but these errors were encountered:
@thesourcerer8 wrote in #27 (comment) :
Right, but memory isn't a scarce resource on modern workstation. And it would be hard to beat modern web browsers anyway (running top, I see 11 chromium processes, each with ~2GB VIRT size).
So yeah, there definitely no need to be shy to make users' life easier using the memory they have (just leave them in the control of that memory). And initial implementation can be as dumb as just making copies of all data structures (there're 2 - address space flags, one byte for each declared address space byte and address properties, more sparse, but also more weight per entry) before making an interactive change operation.
The concern here would be not memory usage, but speed of copying, I filed #37 in that regard. It should still be good for a typical under-1MB "embedded" project. And if larger projects will show issues, we can think about that later (the ideas are there - e.g. for flag space implement copy-on-write arrays, which would store only changed "pages", and props are fine-grained already, so only changes can be stored).
So, the idea is that user would be able to control levels of undo stored, and that will control amount of memory taken.
The text was updated successfully, but these errors were encountered: