[L2Ork-dev] dynamic patching and undo/redo system

[Albert Graef]

On Fri, Jul 31, 2020 at 5:34 AM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> What I mean is how do we differentiate between dynamic patching and a)
> loading a patch or b) regular patching through
> the g_editor.c event callbacks?
>

Hmm yes, you're right. But after loading a patch its undo history should be
empty anyway, right? (This assumes that the undo history is being kept
locally in each patch, if not then all this becomes much harder.) So then
we just need to distinguish dynamic patching from the g_editor.c event
callbacks, in which case the necessary breadcrumbs could possibly be
provided by the undo engine, or by those callbacks themselves. Yeah, it
won't be pretty I'm afraid. :(

Albert

For example, there are no breadcrumbs left in canvas_obj to tell the
> difference. And I'd hate to add a bunch more globals
> to track "is_loading_stuff", "is_editing_stuff",
> "is_dynamically_patching", etc.
>
> -Jonathan
>
> >
> > Albert
> >
> >> > On Mon, Jul 27, 2020 at 3:48 AM Jonathan Wilkes <
> jon.w.wilkes at gmail.com> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> It appears that dynamic patching nnd the undo system are
> irreconcilable.
> >> >>
> >> >> For example-- Suppose you do this:
> >> >>
> >> >> [namecanvas foo]
> >> >>
> >> >> [obj 20 20 clip(
> >> >> |
> >> >> [send foo]
> >> >>
> >> >> Whenever you click the message box, a new object will be created but
> >> >> without any undo history.
> >> >>
> >> >> That's probably desirable behavior, as we don't want a bunch of
> >> >> dynamically created gumming up the undo system.
> >> >>
> >> >> However, the undo system is based off object indices. So by inserting
> >> >> "[clip]" into a glist we corrupt that system. You can see this if
> >> >> dynamic patching in the middle of other editing actions. Doing undo
> >> >> then redo will put the patch in a corrupt state because the indices
> >> >> will be off by one due to the "[clip]" object that the undo system
> >> >> didn't expect.
> >> >>
> >> >> I don't know any clean way to deal with this. But it affects more
> than
> >> >> dynamic patching:
> >> >>
> >> >> [pointer(
> >> >> |
> >> >> [canvasinfo]
> >> >> |
> >> >> [20 20 $1(
> >> >> |
> >> >> [append some_scalar x y]
> >> >>
> >> >> Same problem there, as well as:
> >> >>
> >> >> [pointer(
> >> >> |
> >> >> [canvasinfo]
> >> >> |
> >> >> [next, delete(
> >> >> |
> >> >> [pointer some-scalar]
> >> >>
> >> >> Each one breaks the assumptions of the undo system and undo/redo
> >> >> actions can have wrong indices.
> >> >>
> >> >> Even more pressing-- now that we've got pointer delete method, the
> >> >> undo system can have an out-of-bounds index and crash when it tries
> to
> >> >> deference a null pointer.
> >> >>
> >> >> Any ideas on how to approach this?
> >> >>
> >> >> -Jonathan
> >> >> _______________________________________________
> >> >> L2Ork-dev mailing list
> >> >> L2Ork-dev at disis.music.vt.edu
> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >> >
> >> >
> >> >
> >> > --
> >> > Dr. Albert Gr"af
> >> > Computer Music Research Group, JGU Mainz, Germany
> >> > Email: aggraef at gmail.com, web: https://agraef.github.io/
> >> > _______________________________________________
> >> > L2Ork-dev mailing list
> >> > L2Ork-dev at disis.music.vt.edu
> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
> >> _______________________________________________
> >> L2Ork-dev mailing list
> >> L2Ork-dev at disis.music.vt.edu
> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >
> >
> >
> > --
> > Dr. Albert Gr"af
> > Computer Music Research Group, JGU Mainz, Germany
> > Email: aggraef at gmail.com, web: https://agraef.github.io/
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200731/ff9e1f28/attachment.html>