[L2Ork-dev] Current HEAD of Purr Data is broken

Jonathan Wilkes jon.w.wilkes at gmail.com
Tue Jun 30 19:22:50 EDT 2020


Albert-- now that HEAD is what it is, what would the process be of
rolling it back while putting all those merges
into a separate nwjs-update branch?

-Jonathan

On Tue, Jun 30, 2020 at 5:57 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>
> On Tue, Jun 30, 2020 at 3:20 PM Ivica Bukvic <ico at vt.edu> wrote:
> >
> > The fix that may have triggered the regression you describe was supposed to fix a regression :-)
> >
> > Namely the code removed that deletes data structures during a redraw also tends to delete all the other objects on a subpatch when an undo action is triggered, leaving only patch cords visible. This was true regardless of the nw.js version. I suspect that the fix that Jonathan originally introduced there may have been because of drawing of the data structures alongside the regular objects on the same canvas, which is what the about page has with the animated cat.
>
> Unfortunately, I can't create a scalar on a canvas at all. This is a
> bug even if there are no gop subpatches in existence.
>
> Also-- I tried reverting the code you're referring to, Ico. Even with
> that code path present, a simple scalar will fail to
> be displayed. Even worse-- nothing gets created on the GUI side. So
> either the problem is something you introduced to
> gui_scalar_new, or in the backend preventing that from every being called.
>
> -Jonathan
>
> >
> > My originally proposed merge request offered deleting only scalars in a situation that the code seemed to address. I also indicated that it needed to be tested further given I was unsure under which circumstances this code would be necessary. The final merge was Jonathan's where he erased that part entirely suggesting it was not necessary anymore.
> >
> > What may be helpful, as the code complexity continues to grow, is to carefully annotate each of these calls in the code so that we can better understand why they are placed there in the first place and what needs to be done to check for regressions.
> >
> > Best,
> >
> > Ico
> >
> > --
> > Ivica Ico Bukvic, D.M.A.
> > Director, Creativity + Innovation
> > Institute for Creativity, Arts, and Technology
> >
> > Virginia Tech
> > Creative Technologies in Music
> > School of Performing Arts – 0141
> > Blacksburg, VA 24061
> > (540) 231-6139
> > ico at vt.edu
> >
> > www.icat.vt.edu
> > www.performingarts.vt.edu
> > l2ork.icat.vt.edu
> > ico.bukvic.net
> >
> > On Tue, Jun 30, 2020, 14:16 Albert Graef <aggraef at gmail.com> wrote:
> >>
> >> Sorry, I missed these remarks earlier.
> >>
> >> On Tue, Jun 30, 2020 at 2:14 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> >>>
> >>> I can confirm running HEAD against a local 0.46.3 nw.js on aarch64
> >>> does indeed work to load and display patches.
> >>
> >>
> >> Have you tried  the Help - About Pd-L2ork menu entry?
> >>
> >>> What do I need to add to the contributor's guide to make it clear what
> >>> a desirable merge request branch should look like?
> >>
> >>
> >> I guess you're talking about workflow here? That is, rebasing and squashing commits so that you present your feature branch a.k.a. merge request as simple and comprehensible as possible, with a clean and logical commit history. There's a lot that goes into that  process and much of it is common sense -- but you'd probably have to replicate half the Git Book to explain these things really thoroughly.
> >>
> >> However, the main failure in this case IMHO was that there weren't enough eyeballs looking at this "patchset from hell", before the changes were merged into master. A call for help on the mailing list goes a long way there, explaining what the new set of changes is about, what parts of the program might be affected, and what needs to be tested. I did notice the flurry of commits, but I wasn't sure what they were about and didn't have the time to look into them. I would certainly have tried to give a helping hand in testing, though, when asked about it in the manner described. ;-) (Or maybe I missed that call, then I have to apologize.)
> >>
> >> Albert
> >>
> >>> > On Tue, Jun 30, 2020 at 11:42 AM Sam Thursfield <ssssam at gmail.com> wrote:
> >>> >>
> >>> >> Hi Albert,
> >>> >>
> >>> >> On Tue, Jun 30, 2020 at 9:12 AM Albert Graef <aggraef at gmail.com> wrote:
> >>> >> > The program still builds fine, launches and I can still open new patch windows (^n), but "About Pd-L2ork" doesn't work any more and I can't open existing patches either (apparently the patches do get opened in the engine, but no window is mapped).
> >>> >>
> >>> >> Is it possible that you are using a version of nw.js >= 0.42.3 ?
> >>> >> This issue sounds a bit like
> >>> >> https://git.purrdata.net/jwilkes/purr-data/-/issues/572
> >>> >> Sam
> >>> >> _______________________________________________
> >>> >> 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


More information about the L2Ork-dev mailing list