[L2Ork-dev] Current HEAD of Purr Data is broken
Ivica Ico Bukvic
ico at vt.edu
Tue Jun 30 21:13:48 EDT 2020
It appears my branch is affected, as well, so it is either something I
did or something that was merged from the main branch. The error is as
follows (on Windows, at least):
C:\Program Files (x86)\Purr Data\bin\pdgui.js:3542 Uncaught TypeError:
Cannot read property 'join' of undefined
at C:\Program Files (x86)\Purr Data\bin\pdgui.js:3542:51
at get (C:\Program Files (x86)\Purr Data\bin\pdgui.js:2057:21)
at Object.get_elem (C:\Program Files (x86)\Purr
Data\bin\pdgui.js:2073:24)
at gui_scalar_new (C:\Program Files (x86)\Purr
Data\bin\pdgui.js:3491:14)
at eval (eval at perfect_parser (C:\Program Files (x86)\Purr
Data\bin\pdgui.js:1885:21), <anonymous>:1:1)
at perfect_parser (C:\Program Files (x86)\Purr
Data\bin\pdgui.js:1885:21)
at Socket.<anonymous> (C:\Program Files (x86)\Purr
Data\bin\pdgui.js:1903:9)
at Socket.emit (events.js:315)
at addChunk (_stream_readable.js:302)
at readableAddChunk (_stream_readable.js:278)
Best,
Ico
On 6/30/2020 8:08 PM, Ivica Bukvic wrote:
> Before we do that, allow me to take a stab at this to see what may
> have broke. I will also test to see if my branch exhibits the same
> problem. What about the plot drawing optimizations you introduced,
> could they be also somehow involved? I don't have those yet on my
> branch and have not experienced any known problems yet, although I
> need to test the about page.
>
> 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 <mailto:ico at vt.edu>
>
> www.icat.vt.edu <http://www.icat.vt.edu>
> www.performingarts.vt.edu <http://www.performingarts.vt.edu>
> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu>
> ico.bukvic.net <http://ico.bukvic.net>
>
> On Tue, Jun 30, 2020, 19:23 Jonathan Wilkes <jon.w.wilkes at gmail.com
> <mailto:jon.w.wilkes at gmail.com>> wrote:
>
> 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 <mailto:jon.w.wilkes at gmail.com>> wrote:
> >
> > On Tue, Jun 30, 2020 at 3:20 PM Ivica Bukvic <ico at vt.edu
> <mailto: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 <mailto:ico at vt.edu>
> > >
> > > www.icat.vt.edu <http://www.icat.vt.edu>
> > > www.performingarts.vt.edu <http://www.performingarts.vt.edu>
> > > l2ork.icat.vt.edu <http://l2ork.icat.vt.edu>
> > > ico.bukvic.net <http://ico.bukvic.net>
> > >
> > > On Tue, Jun 30, 2020, 14:16 Albert Graef <aggraef at gmail.com
> <mailto: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 <mailto: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 <mailto:ssssam at gmail.com>> wrote:
> > >>> >>
> > >>> >> Hi Albert,
> > >>> >>
> > >>> >> On Tue, Jun 30, 2020 at 9:12 AM Albert Graef
> <aggraef at gmail.com <mailto: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
> <mailto: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 <mailto:aggraef at gmail.com>, web:
> https://agraef.github.io/
> > >>> > _______________________________________________
> > >>> > L2Ork-dev mailing list
> > >>> > L2Ork-dev at disis.music.vt.edu
> <mailto: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
> <mailto: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 <mailto:aggraef at gmail.com>, web:
> https://agraef.github.io/
> > >> _______________________________________________
> > >> L2Ork-dev mailing list
> > >> L2Ork-dev at disis.music.vt.edu
> <mailto: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 <mailto: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 <mailto:L2Ork-dev at disis.music.vt.edu>
> https://disis.music.vt.edu/listinfo/l2ork-dev
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200630/52ed8963/attachment-0001.html>
More information about the L2Ork-dev
mailing list